Singleton patterns and __set_state()

[Paladin]

Noted many uses of the singleton pattern, or strictly speaking,
something similar to the singleton pattern. I say similar, because
they poke holes in a couple of the responsibility firewalls in the
pattern. Which of course brings up the question of "intentional or
not?" I don't see the purpose, but then I don't see everything.

Proper singleton patterns should have the constructor function
declared private, as well as the instance property, so the only public
access is through getInstance. This part of the pattern is broken many
of the times I've seen it.

They should also override the __clone "magic method" to prevent
breakage of the "sole responsibility" requirement; if an object can be
cloned, then there is no longer just one object.

Also, in order to do some of the testing, I'm writing another "magic
method" -- __set_state() -- for some objects. Is there going to be
resistance to putting them in the core code? Most of the time they
simply take the array of properties and return an instance of the
object. (phpunit uses this function when run with isolated processes).

[Louis Landry]

I don't envision any resistance to adding those things to the core code.  As for the singleton-esque things you are seeing, some of that is simply coming from the PHP 4.3 world where there is really no such thing as singleton except in theory because you don't have actual access modifiers, etc.  Some of it is oversight, and in some cases it may be by design.  Would have to look at them all one by one to get there.

You are doing great stuff!  Thanks!

- Louis

--
Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org

[Paladin]

On Nov 17, 10:04 am, Louis Landry <louis.lan...@joomla.org> wrote:
> I don't envision any resistance to adding those things to the core code.

I'm holding off on working those until phpunit 3.4.3 is released, in
case it takes care of that sort of thing for me. The word is it fixes
a lot of the isolation problems, so the set_state code may no longer
be necessary when it ships.

[Louis Landry]

Sounds good.

Do you think it would be useful to create a branch off of trunk ... say "testable" ... where you are able to make smallish changes like you've been working on to make things more testable, or fixing up miscellaneous oversights?  We could do that, and just merge back down to trunk from time to time.  Just a thought.

- Louis

[Paladin]

On Nov 20, 1:37 pm, Louis Landry <louis.lan...@joomla.org> wrote:
> Sounds good.
>
> Do you think it would be useful to create a branch off of trunk ... say
> "testable" ... where you are able to make smallish changes like you've been
> working on to make things more testable, or fixing up miscellaneous
> oversights?  We could do that, and just merge back down to trunk from time
> to time.  Just a thought.

In a way, I've been doing that. I've made small changes on my local
system where I've needed to (quick check shows 6-10 changed files). I
haven't sent them in because I don't have a good enough grip on things
yet to know whether they're the right changes (I've reverted another
4-6 changes in the last week). Most, if not all, of the patch files
I've sent in are for fixing bugs, or cleaning up, not making changes
to improve testing.

Right now only 1/8 of the libraries tree is under test. Once we have a
lot of the system under test, we'll have a better view of what we need
to do in order to improve testability. If we start doing that now, we
run the risk of making a series of small changes to improve some tests
which later on we'll have to undo because what looked like The Right
Way turned out to be a cul de sac.

This is a "long haul" operation, maybe as much as 4-6 months (my
current stats say almost 22k lines, 1725 methods, 265 classes) to
bring most of it under test. I wouldn't expect to be able to make
judgements like that until Jan 2010, at least.

Maybe Ed, Ian or Niels might have a different view of it, but it's not
necessary for me. The "fun" of working with subversion branches isn't
worth it.