Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44860
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain born05.nl from 217.19.16.165 cause and error)
To: <internals@lists.php.net>
References: <7.0.1.0.2.20090708224156.0ac5a438@zend.com> <af54caaf0907090139q23a5574fscdcf29321c7f8f0e@mail.gmail.com> <7.0.1.0.2.20090709121921.0ae17d58@zend.com>
In-Reply-To: <7.0.1.0.2.20090709121921.0ae17d58@zend.com>
Date: Thu, 9 Jul 2009 12:49:44 +0200
Message-ID: <000001ca0082$f8c15a10$ea440e30$@nl>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcoAejR7Qnenp36XT2WmcmqOIA7QzgAAmREQ
Content-Language: nl
Subject: RE: [PHP-DEV] Type hinting - Request for Discussion
From: dennis@born05.nl ("Dennis Haarbrink")



> -----Oorspronkelijk bericht-----
> Van: Zeev Suraski [mailto:zeev@zend.com]
> Verzonden: donderdag 9 juli 2009 11:46
> Aan: Paul Biggar
> CC: internals@lists.php.net
> Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion
>=20
> At 11:39 09/07/2009, Paul Biggar wrote:
> >I believe nearly all opinions voiced have wanted the current patch.
> >Many more were in favour of strict typing only, but for the few
> >dissenters, like myself, Ilia included casting semantics using (int)
> >syntax.
>=20
> I think that many of the people who expressed
> support for that patch did not fully realize its
> implications - much in the same way they weren't
> quite realizing they're actually voting for
> inclusion in PHP 5.3.  I believe that if we had a
> 'clean' Weak typing RFC as well as a Strict
> typing RFC, each with its pros and cons - there
> would be very different results.
>=20
> >There are I think maybe 5 or 6 people who have expressed opinions
> >against this. All others have been pro (I'm not counting the vote
> >here, I'm looking at discussions).
>=20
> I think you're right, but I also think it had to
> do with dynamics more than with actual content.
> The two approaches were never compared
> head-to-head, with the pros and cons - and more
> importantly - with use cases on why strict typing
> is necessary despite the fact it's fairly 'alien' to PHP.
>=20
> > > 2. =C2 Make sure people understand *why* we're
> > implementing it - performance is
> > > certainly *not* the reason.
> >
> >I believe there was only two misguided souls who believed this would
> >lead to better performance. Everyone else wanted it on its merits.
>=20
> Maybe - but the only way to make sure is to make it a clear part of =
the
> RFC(s).
>=20
> >It doesnt sound like you are aware of the casting semantics that Ilia
> >added. They are largely consistent with the internal function
> >semantics.
> >
> >function x (int x) { /* fail on non-int */ }
> >function x ((int) x) { /* cast parameter to an int */ } // just like
> >internals functions
>=20
> I am - and I think I like this even less than
> pure strict typing because of increased WTF factor.
> I think strict typing is wrong for PHP, and this
> cannot be fixed by also adding something
> else.  The way to 'fix' this is by not adding
> strict typing, and adding only weak typing.
>=20
> >Indeed this adds the ability to make your function work like an
> >internals function (useful perhaps for library interfaces).
>=20
> If improved with slightly more intrusive checks
> (like the ones suggested in my email) - then it
> can be useful in mostly all of the places where strict typing would be
> used.
>=20
> > > I think we can take Lukas's RFC and either change it or write
> something
> > > based on it for weak typing only. =C2 If people here find it =
useful
> I'll go
> > > ahead and do that.
> >
> >I believe people don't want this. I wrote a set of rules, Lukas wrote
> >the RFC, and neither got anything like the support that strict typing
> >got.
>=20
> This could be for a variety of reasons - one of
> them is that people truly thought this through
> and truly prefer strict typing to weak
> typing.  But that is just one of the
> options.  Another is that the difference between
> the two approaches, as well as the issues with
> strict typing - aren't fully understood by the
> audience - and I believe that this is actually the case.
>=20
> >One large problem is that it introduced a new 3rd set of rules, and
> >this set is not intuitive but rather slightly subjective (reasonable
> >people might disagree on whether a bool should be weakly converted to
> >an int, for example). The strict type checks are at least simple, and
> >the current weak ones are what people are used to.
>=20
> I definitely don't think we should add two new
> semantics.  Ideally we shouldn't add any
> entirely-new semantics, and what I'm proposing is
> to actually reuse the existing semantics for
> internal functions - with very minor
> modifications.  Kind of like Semantics and
> Semantics', rather than Sematnics1, Semantics2, Semantics3.
>=20
> >Obviously I'm not against discussion, but we just had this =
discussion.
>=20
> Given the implications of introducing something
> like that (that can easily grow in the future to
> other parts of PHP) - and my belief that the
> discussion missed key ingredients, we should discuss it further.
>=20
> We need to go back to the fundamentals - and look
> for use cases where strict typing would be
> substantially superior to weak typing.  As far as
> reflection, code readability, optimization and
> security is concerned - I can't find any
> superiority, but maybe I'm missing something.  We
> already have an RFC that details the
> disadvantages of strict typing (Lukas's
> RFC).  Let's focus on the advantages and see if they're worth it?
>=20
> Zeev
>=20



I am a long time (passive) list reader but seeing the direction of this
discussion makes me feel obligated to express my opinion.

I'm a framework developer and I have great interest in type =
hinting/casting.
I'm all for clarity and strictness, but it should definitely be a =
choice.
PHP is known for its easy learning curve, that is one of its big powers =
and
that should remain unchanged. But the way I see it is that it can be
implemented without *requiring* you to use it, if you want to use type
hinting/casting go ahead, if you don't want it, well, leave that bit =
alone.
If it comes with a minor performance hit, OK, i can live with that, I =
agree
with Lukas in that aspect, you don't spend lots of time checking/casting
anyway.
As for hinting/casting would not be 'php-ish', i don't see it that way, =
i
look at php as a language of possibilities, not restrictions.

As  I said, i'm a framework developer and it would greatly improve
readability, usability and quality when you can use type =
hinting/casting.
Consider a pretty common architecture where you have a service layer =
which
does validation and stuff and then passes control to 'deeper' parts in =
the
framework. Your service layer could have a casting hint, while the more
inner components could have a strict hint. There you can trust the data =
is
of the type you wanted, otherwise there is something wrong anyway.

The most important thing is that it is _optional_, you have the _choice_ =
to
use it.
Regarding syntax, to me it is totally intuitive that foo((int) $bar) =
tries
to do a cast and foo(int $bar) is strict, it's also easy to explain to
students, put parenthesis around your type name and it's a cast, whether =
it
is in an assignment or a method declaration it doesn't matter.

Seeing the discussion I think there is consensus it shouldn't be in 5.3. =
I
think it shouldn't be in 5.x total, the 5.x branch is already _loaded_ =
with
lots of new cool stuff and in my opinion all focus should be on getting =
a
6.0 release asap.

I know, i'm 'just' a php user but maybe I can inspire someone in taking =
the
'right' course.

Regards,
Dennis Haarbrink