Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61695
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=utf-8
In-Reply-To: <CAKZjf5T8o-TBcur=+wQH7d_HfRDVJHuvn4oCFHo4xv0cGXU5Gg@mail.gmail.com>
Date: Tue, 24 Jul 2012 19:25:56 +0300
Cc: Galen Wright-Watson <ww.galen@gmail.com>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <4024424F-2D65-41EA-8E18-B2B8FCE94754@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>
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 19:18, Alex Aulbach wrote:

> 2012/7/24 Galen Wright-Watson <ww.galen@gmail.com>:
>>> Don't see much difference between
>>>=20
>>> $a =3D $b ?: $c;
>>>=20
>>> and (for example I used "i" for "if")
>>>=20
>>> $a =3D _i($b, $c);
>>=20
>>=20
>> When $b is defined, there isn't much appreciable difference. However, =
this
>> behavior already exists, so there isn't much to debate. In the cases =
under
>> discussion, a userland function can't suppress undefined variable & =
index
>> notices, so it isn't a viable substitution.
>=20
> Hm, you're right. I normaly don't do such ugly things. :)
>=20
> Hum. This behaviour is needed in very special contexts. In my eyes
> only when printing out/filling up the templates etc. Under normal
> circumstances I think, you should program without too much operators,
> because a deflation of operators leads to - hm - deflation of the
> language. Thats the same, as if everybody can create new words: after
> a short time, nobody can understand anybody.
>=20
> Hmmmm. But we can make this to a principle in this very, very closed =
context.
>=20
> So: What about if we can create new operators inside PHP with PHP? I
> think not more than 36 operators are needed at any time in a project.
> So we can do this:
>=20
> set_operator_handler('i', function ($b, $c) {
>        if (empty($b)) return $b;
>        return $b;
> }, OPERATOR_HANDLE_UNSET_WITHOUT_WARNINGS)
>=20
> then we can do this:
>=20
> $a =3D $a ?i: $b;
>=20
> This should help for this case and could be a great things for those
> very special cases, when you need the same operation over and over.
>=20
> Comments
> ----------------
>=20
> Context: I think those operators should be global.
>=20
> Security: Hm. Could operators be overwritten? How to test, if an
> operator already exists? I think it should work like including a file.
> E. g. set_operator_handler_once() should be possible, so that a second
> call isn't executed.
>=20
> Other things: I don't like the first operator (the operator-name). Any
> goof idea?
>=20
>=20
> --=20
> Alex Aulbach
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20

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"
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.