Re: Implicit isset in ternary operator

On 24 ביול 2012, at 20:15, Alex Aulbach wrote: > 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. > Yeah, that's a design decision, but its important because that's one of the PHP greatest things - the code is very nice and readable, and it's kind of sad to ruin it... I didn't thought about template engines - I agree, it'll be great there, but does a language syntax need to be defined only for a specific cases like template engine? > >> 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 If the programmers will follow your guidelines and use this operators only for some unique and rare cases - I strongly support that idea, but I'm afraid from programmers who'll make their program full of operators which makes it unreadable by other programers... I think that operators overriding should be implemented in a class scope (only for object with object interaction, such as (merge operation): $mergedMember = $member1 + $member2; or for roles permission concat - $memberRule = $adminRule - $editorRule) But that's a different topic from the suggested feature...