Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34434
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Date: Fri, 4 Jan 2008 10:08:40 -0800
Message-ID: <698DE66518E7CA45812BD18E807866CE01103EB7@us-ex1.zend.net>
Thread-Topic: [PHP-DEV] RE: Optional scalar type hinting
Thread-Index: AchO2HpLxdjLtc16QGGWNWCWVFcRcQAIf15Q
References: <200801031903.01980.tomi@cumulo.fi> <698DE66518E7CA45812BD18E807866CE01103E21@us-ex1.zend.net> <1199454404.15292.123.camel@sbarrow-desktop>
To: "Sam Barrow" <sam@sambarrow.com>
Cc: <internals@lists.php.net>
Subject: RE: [PHP-DEV] RE: Optional scalar type hinting
From: andi@zend.com ("Andi Gutmans")

See below:

> -----Original Message-----
> From: Sam Barrow [mailto:sam@sambarrow.com]
> Sent: Friday, January 04, 2008 5:47 AM
> To: Andi Gutmans
> Cc: internals@lists.php.net
> Subject: RE: [PHP-DEV] RE: Optional scalar type hinting
>=20
> On Thu, 2008-01-03 at 21:34 -0800, Andi Gutmans wrote:
> > We've discussed scalar type hinting many times in the past and
> decided
> > against it.
> > It really doesn't fit in very well with PHP's loosely typed nature
> which
> > is one of the main reasons it has been so easy to use. The only
> reason
> > why it works with classes and arrays is because those are
unambiguous
> > constructs.
>=20
> It doesn't fit. This is not a technical argument, this is your opinion
> on the way PHP should be. That's the problem here.

Are you saying that languages are designed only based on technicalities?
So why are languages so different? Each language has a spirit and an
emphasis and this is definitely something to think about. It also
relates to what the applicable market and users are.

-snip-

So why don't we first see if people can agree on what this does:

I think all the following ones should work:

function iwantint(int $n) {
iwantint("1");			// "1" + 1 works great.

function iwantstring(string $str) {}
iwantstring($toStringObject); // Works in strcmp()

function iwantfloat(float $f) {}
iwantfloat(2);

function iwantbool(bool $b) {}
iwantbool(1);

function iwantnull(null $n) {}
iwantnull(null); 		//Does this exist?


And for consistency of the language we would be using PHP's type
juggling system to see if there's a match or not and you'd get whatever
results you get today.

Btw I think there's absolutely no argument that the error should be
exactly the same as with array/class hints. No way are we going to have
two different errors for the same kind of functionality. That's
ludicrous.

More below:...

> > Saying that it won't confuse newbies is also wrong. PHP is so
popular
> > because it's so easy for people to pick up. Part of this also
> includes
> > ability to look at other people's code, understand it, copy-on-write
> > (e.g. a Wordpress plug-in). The more features in PHP the harder
it'll
> be
> > for developers to deal with. Yes, we bit the bullet for namespaces
> > because there were strong reasons in favor of it, we as a community
> had
> > it on our wishlist for a long time and a lot of work went into it.
> And
> > even when we did it we had to find a way to make it work for PHP. In
> > this case, with the lose typing of PHP creating a consistent model
> which
> > will be apparent to people without many questions is a big issue.
>=20
> I've said this numerous times too. How hard is it to understand? If
> someone can't understand this simple concept they are sure as hell not
> going to understand object oriented or anything.

There are actually a lot of PHP developers who don't do OO oriented.
This is why we left it as a choice to developers (it's been around btw
since 1997 at least the basic OO functionality).

Anyway what's confusing here are the semantics not the feature itself.
For example, I expect something different than you do.

> Plus the fact that this is actually easier to understand than
> array/object type hints.

I don't think so because there's no potential type juggling in those
(which is why we did it) but it's a pointless argument because it
doesn't add much value to the discussion.

> > Also, for those who say that when this feature is not used it
doesn't
> > have a performance impact that is also a problematic statement. If
it
> > exists people will use it. Most people using PHP don't understand
> (and
> > shouldn't have to understand) how the language is implemented. It
may
> > very well be that even if we could agree on the semantics we'll see
> all
> > sorts of developers "decorate" their code with type hints (because
> they
> > think it'll help readability) who may down the road find themselves
> in a
> > surprise when it comes to performance.
>=20
> Well that's their decision. I could use functions and not use a single
> class in my applications, and they would be faster. I sacrifice a
> little
> performance in order to make my code better.
>=20
> > Last, just because something can be implemented and a patch exists
> > doesn't mean it should be in PHP. There are lots of things I can
> > implement for PHP which shouldn't be in PHP. Also don't under
> estimate
> > what happens when you get bloatware and over time how much harder it
> > becomes to maintain and also how it does eventually end up slowing
> > things down (over time there are more branches, more code a.k.a more
> > cache misses, etc...)
>=20
> You are right here. But define bloatware. Type hinting is already in
> PHP. All I want to do is add a couple of types to this already
> implemented feature. My patch is pretty small.
>=20

Small small but the way it is currently implemented I both don't agree
with (semantics) and I think it can also be implemented better (for
starters I'd use a switch() statement in the runtime piece. I am not too
worried about zend_compile.c).

> > P.S.- The runtime piece of this patch also looks wrong. I didn't
dive
> > deep but those if() statements don't look too friendly.
>=20
> It's worked for me fine for a couple of months. The if statements in
> zend_compile.c are pretty confusing (as far as the brace indentation
> goes).

I'm sure it worked fine for you but I don't think I agree with the
semantics and I believe implementation could be improved.

Andi