[dev] [commits] Horde branch master updated. e69d55f2aea69e68acc6ba1017e2758f5399843e

Jan Schneider jan at horde.org
Mon Nov 1 14:16:10 UTC 2010


Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>
>>>   Allow ability to search session subkeys.
>>>
>>>   We store values with key & subkey together to save on  
>>> storage/serialization
>>>   costs. To retrieve array like output, simply need to call
>>>   $session['app:name/'] - returns an array with subkeys as keys and session
>>>   values as values.
>>
>> This sounds like a bit too much magic for a small performance gain.  
>> I'd rather like this to be a real array for  
>> readability/maintainability, and loose a bit of performance. Can't  
>> be too much anyway.
>
> Disagree.  I personally am finding that storing something with a  
> session index like:
> ['imp:imp_mailbox/INBOX']
> is *much* clearer (since all the pertinent information is in the  
> same string and not separated by PHP-ish cruft) in the code than:
> ['imp']['imp_mailbox']['INBOX']
> not to mention easier to write and less prone to typos/errors.
>
> Especially since I have only found *1* instance in the code so far  
> where we were actually using the iterative/collective property of  
> arrays (the horde:auth_app variable).  In every other instance, we  
> are carrying around the overhead of an array data structure solely  
> for the fact that it might make things a bit clearer in the code -  
> but, as I argue above, that is not true anymore either.
>
> But nothing I have added will prevent anybody from storing arrays if  
> they want.

I feel rather strong about this being counter-intuitive. Any other  
opinions about this?

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/



More information about the dev mailing list