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

[Chuck Hagenbuch]

Quoting Jan Schneider <jan at horde.org>:

> 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?

I'm fine with flattening out the keyspace. But the magic syntax and the global array that isn't actually an array bug me.

-chuck