[dev] [commits] Horde branch master updated. 85e306b9042c49634b25d0a3d1573366576fc165

Michael J.Rubinsky mrubinsk at horde.org
Fri Oct 22 15:32:21 UTC 2010


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

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>> Quoting Chuck Hagenbuch <chuck at horde.org>:
>>>
>>>> commit 85e306b9042c49634b25d0a3d1573366576fc165
>>>> Author: Chuck Hagenbuch <chuck at horde.org>
>>>> Date:   Thu Oct 21 15:23:46 2010 -0400
>>>>
>>>>  Don't throw a warning if the global doesn't exist
>>>>
>>>> framework/Core/lib/Horde/Core/Browser.php |    7 +++++--
>>>> 1 files changed, 5 insertions(+), 2 deletions(-)
>>>>
>>>> http://git.horde.org/diff.php/framework/Core/lib/Horde/Core/Browser.php?rt=horde-git&r1=a7c7c74a95a0a3947850d2f9b4bc51365b69c17a&r2=85e306b9042c49634b25d0a3d1573366576fc165
>>>
>>> There's no need to check the indices of a session variable - if  
>>> the index doesn't exist, Horde_Session will automatically return  
>>> null instead of throwing an undefined index error.
>>>
>>> It must be $GLOBALS['session'] itself that doesn't exist so the  
>>> check should be for that.  (Not a big deal, but figured it was a  
>>> good place to identify an advantage of Horde_Session since I  
>>> haven't finished writing the docs yet).
>>
>> Is there a reason that Horde_Session uses a global with array  
>> semantics? Makes it feel very magic, and not being familiar with  
>> its internals, I had no way of knowing the above - nor does anyone  
>> looking at how it's used. In fact I didn't even know that  
>> $GLOBALS['session'] was a Horde_Session object.
>
> That's simply because the documentation hasn't been finalized yet.
>
> I thought of using hsession instead of session, but went for the  
> slightly shorter name because I thought it is clearer.
>
> Session data is essentially a key -> lookup action so array  
> semantics work great.  I am definitely NOT for the idea of having  
> some method do this for us.  For me, I would much rather  
> type/use/read:
>
> $session['horde:foo']
>
> than
>
> $session->getValue('horde', 'foo')
>
> I find it MUCH easier to read the former rather than the latter  
> (it's one of the reasons why I would support changing  
> $prefs->setValue() and $prefs->getValue() calls to using array  
> semantics - the method calls are just way too wordy for something  
> that is used a bunch).
>
> Obviously, we could add get/set method calls but I would rather be  
> consistent with usage.

I think I'm with Chuck here. This seems too magical.  Reading the  
code, $session looks like an array. I expect it to *be* an array.  
IMHO, it seems that using a set/get method would make this much  
clearer. The array keys seem magical to me as well, and I struggled  
with finding out where ';object' and ';array' were dealt with, but I  
can see how keeping them will simplify things.


--mike

The Horde Project
http://www.horde.org


More information about the dev mailing list