On 24 ביול 2012, at 20:15, Alex Aulbach wrote:
> 2012/7/24 Yahav Gindi Bar <g.b.ya...@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...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
