Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61710
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=utf-8
In-Reply-To: <CAKZjf5Tgij9PraeJ_W7qNwEbGtxcdONRDG48-w8e7EyGCZ4VYA@mail.gmail.com>
Date: Tue, 24 Jul 2012 20:50:09 +0300
Cc: Galen Wright-Watson <ww.galen@gmail.com>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <64388090-395E-4A37-B6C7-4ABE628D0AD7@gmail.com>
References: <CAOhuFvYD8FQw=xbK3hFqi4GYkOvCNzWjuhk2fqwBjKG9n2kuuQ@mail.gmail.com> <CAKZjf5T517=_fmrTRo78y4G8cM8-E1jbXfLcN3Z8H44mBjg9rQ@mail.gmail.com> <CA+Ky_uMv7HN44oXK29XtQNQLyFSn_rPb5jOrDyJrXFau30=LWw@mail.gmail.com> <CAKZjf5T8o-TBcur=+wQH7d_HfRDVJHuvn4oCFHo4xv0cGXU5Gg@mail.gmail.com> <4024424F-2D65-41EA-8E18-B2B8FCE94754@gmail.com> <CAKZjf5Tgij9PraeJ_W7qNwEbGtxcdONRDG48-w8e7EyGCZ4VYA@mail.gmail.com>
To: Alex Aulbach <alex.aulbach@gmail.com>
Subject: Re: [PHP-DEV] Implicit isset in ternary operator
From: g.b.yahav@gmail.com (Yahav Gindi Bar)


On 24 =D7=91=D7=99=D7=95=D7=9C 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"
>=20
> 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.
>=20
> But I wouldn't like to see this operator-stuff using in a "normal"
> context, in "normal" PHP-scripts. (What's normal?)
>=20
> 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:
>=20
> set_operator_handler('r', function ($user, $current) {
>    ....
>    if (!$userrRights->userHasRights($username, $current)) {
>         throw userRightsException(....)
>    }
> }
>=20
> and in the code:
>=20
> try {
>     $user ?r: $current;
> } catch
> ....
>=20
> 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?"]
>=20
> 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.
>=20


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?

>=20
>> 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.
>=20
> 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. :)
>=20
> 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.
>=20
> --=20
> 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 =3D $member1 + $member2; or for roles permission concat - =
$memberRule =3D $adminRule - $editorRule)
But that's a different topic from the suggested feature...=