Re: Implicit isset in ternary operator

2012/7/24 Yahav Gindi Bar <g.b.yahav@gmail.com>: > I don't think global operators is good idea since it can make a script very complex and > you'll have to learn many operators in case the one who wrote it decided to make it > "operator driven" On the other hand: If those operators aren't global, then they are local. I wouldn't like that much more, because inside "your project" you will then never know, if and how an operator is currently working. Much more confusion. But I wouldn't like to see this operator-stuff using in a "normal" context, in "normal" PHP-scripts. (What's normal?) I see those operators in a very limited context, e.g. when you create output (use PHP as template-engine), then they could be extremly helpful. Always and alyways repeating things, which can't be made shorter. For example checking the rights of a user: set_operator_handler('r', function ($user, $current) { .... if (!$userrRights->userHasRights($username, $current)) { throw userRightsException(....) } } and in the code: try { $user ?r: $current; } catch .... Ugly? Yes!!! Very! But that's wanted, because - as said - in very special context. [But really? You can read the code as: "Has the user the rights for current?"] In the end this is a design-decision. I wouldn't recomend this for the normal work (as shown above) and I think the said should be part of the documentation - if it is really implemented. But I think in some very special contexts this could be really helpful. > However, if we're talking about operators, I do think that adding operator override option > (for the regular operators, such as +, -, * etc.) will be great for OOP - but that's a > different topic. Existing operators shouldn't be changeable. My suggestion is the "PHP-way" of operator driven development for a very special problem, which is making very repeating but complex things very short, nothing else. :) Or in other words: In detail it's great, but in general it's a very bad idea. :) That's just wanted and if you think you must use it, then you should have a good reason. -- Alex Aulbach