Hello Jason, here is your operator patch: http://marcus-boerger.de/php/ext/ze2/ze2-ifsetor-20040416.diff.txt
currently it uses the following syntax: $var $: $defaul which would equal isset($var) ? $var : $default Notice that at the moment the operator is '$:' and not '?:'. This is because i haven't looked on how to solve the conflicts i get when i use '?:'. If there is more interest in that operator i could invest more work in trying to fix that problem. best regards marcus According to your options and the possibility to implement this as a function. That would only work as a parser internal function like empty or set. Doing so would be very easy i guess. Though it would require a new keyword say 'ifsetor' (which reflects its purpose more as 'setor'). best regards marcus Friday, April 16, 2004, 1:08:18 AM, you wrote: > Hello, > Let me make an attempt to clarify what I originally requested. > ------ > A function/construct named setor() modeled after isset(), which takes 2 > parameters: > parameter 1, the variable in question > parameter 2, the default value > if(isset($parameter1)) > return $parameter1; > else > return $parameter2; > The following requirements would apply: > 1. The function would not throw a notice if $parameter1 was not set > 2. The second argument would not be evaluated unless it was actually needed > 3. The first argument would not be modified in any way. > ------ > After a lengthily discussion today on the internals list, I have come to > the conclusion that this is not possible to adhere to all three of the > above requirements in user-land, but would be simple to do in internal-land. > We have more-or-less concluded that an operator would not be the way to > go. We have also seen a general consensus that this would be a highly > helpful feature for developing in E_ALL error mode. > I'm not quite sure how the decision making process goes on in this project, > is it Andi that has the final say? > I would like to see a general consensus on: > 1. Is it a feasible feature that would not interfere with the overall goals > of PHP? > 2. If so, can we schedule it to be implemented in a upcoming version of PHP? > 2. If not, can I pay an experienced developer to take the time to implement > it into an upcoming version of PHP? > I'm not trying to get in the way of the PHP development process, frankly, > I'm new to this side of things. But I do have quite a few personnel on > payroll that I think would benefit significantly by having a this feature > added, which is why I would be willing to pay for it's implementation, > which in turn everyone can benefit from. > Thanks again, > Jason Garber > President > IonZoft, Inc. -- Best regards, Marcus mailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
