Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83493
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender)
To: =?utf-8?Q?'Pavel_Kou=C5=99il'?= <pajousek@gmail.com>
Cc: "'Zeev Suraski'" <zeev@zend.com>,
	"'PHP internals'" <internals@lists.php.net>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>	<002101d04ea0$d92ea0f0$8b8be2d0$@tutteli.ch>	<CAB6YZuzKZAiSbzq7+yOsZ4wqKMTR1myemuPqEsDUAqpNzMnHBg@mail.gmail.com>	<000601d04ecd$95545aa0$bffd0fe0$@tutteli.ch>	<CAB6YZux0DpbNBMiz4M7eyJ5Mk6qpFSu8gRU_GNn+cpwRfbAxOA@mail.gmail.com>	<000d01d04ee0$0d03fb70$270bf250$@tutteli.ch> <CAB6YZuxt-iyqTzPHeKsCmvDEZnj9xmDj3PEmT8VU_DjwyTkxcg@mail.gmail.com>
In-Reply-To: <CAB6YZuxt-iyqTzPHeKsCmvDEZnj9xmDj3PEmT8VU_DjwyTkxcg@mail.gmail.com>
Date: Sun, 22 Feb 2015 23:07:03 +0100
Message-ID: <002101d04eeb$e3fd8c30$abf8a490$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQKcPg+jpyYspJS11b5G1A7RBHpKTgIhFZZKAamJpWwBSbXevgLCo6mHAimhGv0BqtiajZsH80Yg
Content-Language: de-ch
Subject: AW: [PHP-DEV] Coercive Scalar Type Hints RFC
From: php@tutteli.ch ("Robert Stoll")

> -----Urspr=C3=BCngliche Nachricht-----
> Von: Pavel Kou=C5=99il [mailto:pajousek@gmail.com]
> Gesendet: Sonntag, 22. Februar 2015 22:18
> An: Robert Stoll
> Cc: Zeev Suraski; PHP internals
> Betreff: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>=20
> On Sun, Feb 22, 2015 at 9:42 PM, Robert Stoll <php@tutteli.ch> wrote:
> >
> > Probably it is a philosophical question how to look at it. IMO the
> > only difference in C# (as well as in Java) lies in the way the
> > conversions are applied. Implicit conversions are applied
> > automatically by the compiler where explicit conversions are applied
> > by the user. The difference lies in the fact that C# is statically
> > typed and implicit conversions are only applied when it is certainly
> > safe to apply one. However, Implicit conversions in C# behave the =
same
> > as explicit conversion since implicit conversion which fail simply =
do
> > not exist (there is no implicit conversion from double to int for
> > instance). That is the way I look at it. You probably look at it =
from
> > another point of view and would claim an implicit conversion from
> > double to int in C# exists but just fails all the time =3D> ergo
> > implicit and explicit are different (that is my interpretation of =
your
> > statement above). In this sense I would agree. But even when you =
think
> > in this terms then you have to admit, they are fundamentally =
different
> > in the way that implicit conversion which are different than =
explicit
> > conversion always fail, in all cases - pretty much as if they do not
> > exist. There are no cases, neither in C# nor in Java which I am =
aware
> > of, where an implicit cast succeeds in certain cases but not in all
> > and an explicit conversion succeeds in at least more cases than the
> > implicit conversion. Hence, something like "a" should also not work =
in
> > an explicit conversion in PHP IMO if it is not supported by the
> > implicit conversion (otherwise strict mode is useless btw.)
> >
> > Try out the following C# code:
> > dynamic d1 =3D 1.0;
> > int d =3D d1;
> > You will get the error "Cannot implicitly convert type `double` to =
`int`" at runtime.
> >
> > We see a fundamental difference between C# and PHP here. PHP is =
dynamically typed an relies on values rather than
> types (in contrast to C#). Therefore, the above code emits a runtime =
error even though the data could be converted to int
> without precision loss.
> > This shall be different in PHP according to this RFC and I think =
that is perfectly fine. Yet, even more important it seems to
> me that implicit/explicit conversions behave the same way.
> > At first it might seem strange to have just one conversion rule set =
in PHP since PHP is not known to be a language which
> shines due to its consistency...
> > OK, I am serious again. If you think about it from the following =
point of view: A user writes an explicit conversion in order
> to state explicitly that some value will be converted (this is =
something which will be necessary in a strict mode). Why should
> this explicit conversion be different from the implicit one? There =
should not be any difference between explicit knowledge
> and implicit one. That is my opinion. If you really do not care about =
data loss and just want to squeeze a float/string into an
> int no matter what the value really is then you can use the @ in =
conjunction with ?? and provide the desired default value
> to fall back on if the conversion fails. If conversions like "a" to =
int really matters that much to the users of PHP then we
> could keep the oldSchoolIntConversion function (as propose in my first =
email) even in PHP 10 (I would probably get rid of
> them at some point).
> >
> > Cheers,
> > Robert
> >
>=20
> Well,
>=20
> I look at it this way (in a simplified manner). Hopefully this will =
make you understand my point of view more.
>=20
> - Implicit conversions work only when you are sure you won't lose =
stuff
> - Explicit conversions are for forcing (casting) variable to become =
another type, and when you are explicitely as user calling
> it, you are aware you can lose values
>=20

I see. I see and think you are not alone with this opinion. I give you =
another example and hope you reconsider your position (up to you what =
position you take afterwards of course).

 Consider the following in C#

class A{}
class B : A{}
class C : A{}

A a =3D new B();
B b =3D a; // will fail, needs a conversion
C c1 =3D a; // will fail, needs a conversion
C c2 =3D (C) a;   //will fail at runtime

And now imagine C# would not be based on types but on values. Then the =
following would be perfectly legal as well:

B b =3D a; //is fine since a is of type B
C c1 =3D c; //will fails since a is not of type C
C c2 =3D (C) c; //still fails since a is not of type C

Or to illustrate it differently. Imagine you have a shop and your main =
currency is $. However, you accept =E2=82=AC as well as long as they are =
banknotes. In this case the customer can insert the banknotes in a =
currency exchange machine at the till.=20
Now imagine the following four use cases:=20
1. A customer buys something with $ -> everything is fine because that =
is your main currency.=20
2. Another customer buys in =E2=82=AC and pays in banknotes, also no =
problem at all.=20
3. A third customer wants to pay in =E2=82=AC but with coins. Your =
implicit rule does not hold and you reject the customer.=20
4. Another customer comes by and mentions explicitly that she wants to =
pay in =E2=82=AC with coins. Suddenly you do not care about it any =
longer and try to squeeze the coins into your machine. Unfortunately it =
does not work at all and what you get out of the machine is nothing.

To me, that is exactly how PHP behaves today. Just take int instead of $ =
and string instead of =E2=82=AC, banknotes are ints wrapped in string =
(e.g. "1") and coins are "a", "b" etc.

I really do not think it is a clever idea to have such a big difference =
between implicit and explicit conversion.  They should behave the same =
way. I do not care if you rename explicit casts to something different =
(I proposed oldSchoolIntConversion, but maybe forceIntConversion would =
be good enough as well).


> Sure, the literal meaning in C# and PHP differs a little bit (because =
of static and dynamic typed language differences and
> stuff), but the
> *intent* is IMHO the same; implicit conversions can happen in the =
"background" safely, while for "dangerous" conversions,
> you have to cast by hand. And I see use cases for both of these types =
of conversions.

C# also has the "as" syntax which is another form of conversion.  But it =
is another form of conversion, uses another syntax and hence can have =
other rules. PHP could also have different conversion rules but they =
should be named differently. Using implicit/explicit and having a =
different behaviour is inconsistent IMO (ok, I said it too often in this =
mail, I'll stop now)

>=20
> Also, you are assuming that there will be a "strict" mode; I sincerely =
hope there won't. Ssince introduction of "2 modes", I
> was always saying that there should be only one mode - I don't really =
care whether it would be strict or weak, but just only
> one.
>=20

I do not assume that there will be one but I leave the door open rather =
than close it (unnecessarily).


> Regards
> Pavel Kouril
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, =
visit: http://www.php.net/unsub.php