[dev] [commits] Horde-Hatchery branch master updated. f0daa2470ea069c3488276d2ecb1f92c6fdc86b3

Chuck Hagenbuch chuck at horde.org
Tue Aug 18 02:30:41 UTC 2009


Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>> commit f0daa2470ea069c3488276d2ecb1f92c6fdc86b3
>>> Author: Michael M Slusarz <slusarz at curecanti.org>
>>> Date:   Fri Aug 7 12:17:37 2009 -0600
>>>
>>>   Initial stab at moving base.php code into Application.php
>>>
>>>   Using IMP as a test case.
>>>
>>>   Proposed usage:
>>>   Every application script directly require_once's Application.php
>>>   This inits HORDE_BASE and Autoloading.
>>>   To init app, call new ***_Application(array('init' => $foo))
>>>   where $foo is either true or an array of options to pass to init().
>>>
>>>   lib/base.local.php is now config/horde.local.php
>>
>> -require_once dirname(__FILE__) . '/lib/base.php';
>> +require_once dirname(__FILE__) . '/lib/Application.php';
>> +new IMP_Application(array('init' => true));
>>
>> Changing from base.php to Application.php is semantic and fine. I  
>> don't like the new IMP_Application line though.
>>
>> First of all, it screams side effects - creating a new object but  
>> not assigning it anywhere.
>
> This is more of a shortcut argument rather than anything else.  Instead of
> $app_ob = new IMP_Application();
> $app_ob->init(true);
>
> Not a big deal but I don't personally have any issues with creating  
> an object and not assigning it to a variable (see, e.g.,  
> prototypejs's  Ajax.Request - you create the request by doing a "new  
> Ajax.Request()" and that's it.)  But I have no objections if we'd  
> rather do things the latter way rather than the former.
>
>> Second, why the 'init' argument? When do we need this kind of  
>> object but not need to init? Is this an instance where a singleton  
>> would be appropriate?
>
> There's a bunch of cases where you don't want to init.  perms() will  
> normally be static data.  authCredentials() can't require init()  
> because there is no user.  No need to call init() for prefs  
> functions since it is known that the user is already logged in to  
> IMP (unlike the other two, this is solely for performance reasons -  
> doing a duplicate init in these functions doesn't hurt anything).
>
> That being said, I have no objections to a singleton.  Especially  
> since we should only need to declare that singleton once in the base  
> class.

I'm going to see how things shake out when I work with Gollem, and  
we'll revisit then - okay?

-chuck


More information about the dev mailing list