[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