Now I’m just wondering, what else could or should be stored there? (examples?) Does it also serve as a place to store your own (application specific) singleton instances?

And before you try to imply I intend to obstruct the development of CakePHP, I recommend you have a look at https://trac.cakephp.org/query?status=new&status=assigned&status=reopened&status=closed&reporter=dho&order=priority

Once again: if all you intend is to obstruct further development, move on to rails.

@Tarique: It’s OT, but I think if you have to singletonise non-singleton classes then something is wrong in your design ;-)

@the_james: Thanks for the explanation, you did it better than I did ;-)

@Repsah: Hm, the title and the last sentence are not thought as an attack, to me they are simply the main message of the article (and not specifically directed at the CakePHP project).

And yes, nate’s change is a move in the right direction, but as you say, something more visible would be helpful.

@cakebaker: the article is very useful, but contains two big mistakes: the title and the last sentence, reading that from a developer point of view generates irritation, I think it falls nicely in your “How to defend yourself in a discussion” article, you’re attacking first in order to prevent attacks, in this case, it’s not working.

@nate, Tarique: Daniel is not wrong when he says that people expect a collection of data to behave like other data collections, if the intended behavior is different then it should be pointed out and throw a warning or error when used in a not intended manner. A simple web developer doesn’t want to know how the class registry works, just wants to use it, if he uses in the wrong way, you have to tell them somehow.

@cakebaker again: I think you should appreciate the change nate implemented as it is in your thought direction, maybe you could simply add that something more visible (warning, error) would help the user understand what is going on.

@all: keep up the good work.

So again, the problem here is semantics and not context. Ideally, the function should throw some sort of error when an attempt to overwrite the value is made (because evidently its not supposed to be used that way). You should not have to have intimate knowledge of the cake core to use this function. It should either work like you think it should (ie operate by normal semantics), or tell you differently at runtime (by returning an error or throwing an exception). It should NOT fail silently.

If ClassRegistry was just a way to store key/value pairs I would say what a waste – why not use associative arrays instead :D

Let me give you an example from the field of usability: If you see a “button”, you expect it behaves like a button, i.e. that you can press it and something happens. If you can’t press it, as it is only thought as decoration, well, then you are irritated.

The same applies for software, and that’s what I tried to show with my example. You see a class that looks like a container for key/value pairs and so you expect it behaves in a certain way. In this case, that existing stuff in the registry gets overwritten when adding an object with the same key. If that doesn’t happen, well, then you are irritated. So you can also see it as a usability issue ;-)

@Nate – returning just true or false just increases the amount of code which the app programmer has to write – trigger_error(“You dolt! Singletons serve a purpose”, E_USER_WARNING ) would be more apt ;)