Jochem Maas wrote:
point 1: regardless of how people think there should be an ifsetor()
in the engine - the devs don't so there wont be one.
Arrrrvvhggghh! Don't you just want to scream!
point 2: anything trying to implement this functionality in userspace
is a hack. (to stregethen that stance: Rasmus reiterated the point a few
days ago [can't remember which mailinglist] that people should be
trying to
write *error free* code - ergo the error suppression is not a proper
solution)
Ok. You CAN NOT implement 'ifsetor/coalesce/filled' in userspace. And
the devs don't want it to exist ... so, WTF?
Dante, live with the hack. :-)
Translate to: Dante, you don't need PHP to be better, adequate is good
enough.
<soap box>
Come on devs, I'm pleading with you. Say it isn't so. You force me to
write so much extra code unless this functionality exists in the core.
Explain to me how every possible thing you might want to do to an array
gets it's own function in the language, but something as trivial as this
gets refused so strongly!
I mean really: array_change_key_case, array_chunk, array_combine,
array_count_values, array_diff_assoc, array_diff_key, array_diff_uassoc, ...
http://www.php.net/manual/en/ref.array.php
You can't tell me that most if not all of these functions could not have
been implemented in userspace? I might use 10% of all the array
functions, but I'd use 'coalesce' and 'filled' daily.
</soap box>
Tell me at least this much. Can these two functions be implemented as
an extension? From what you know about PHP internals, does what WE want
have to be a language construct? If I can write coalesce() and filled()
as extensions, I'll submit a new extension/patch. Maybe it could join
PECL and with popularity make it's way begrudgingly into the core?
Dante
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
