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.
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
