On Fri, 2008-01-04 at 10:08 -0800, Andi Gutmans wrote:
> See below:
>
> > -----Original Message-----
> > From: Sam Barrow [mailto:[EMAIL PROTECTED]
> > 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
> >
> > 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.
> >
> > 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.
True. I'm saying that this is being taken too far in this case. PHP with
type hinting is still PHP, I am not asking to redesign the entire
structure of the language.
> -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?
Null hint does not exist, as null is only one value and it would be
pointless.
I've stated my opinion on this, I'm going for standard hinting. Int
means int, not "1" or "one" or "1one". Bool means boolean true or false,
not "true", 1, 0, "0", etc.
>
> 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.
Errors should all be the same for any type hint.
> 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.
> >
> > 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).
OK. And they're not using OO right? So tell them not to use type hinting
either!
> 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.
You have a point, but it is still a very simple concept.
> > > 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.
> >
> > 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.
> >
> > > 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...)
> >
> > 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.
> >
>
> 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.
> >
> > 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.
Semantics can be changed, my only goal is to enable scalar type hinting in PHP.
Implementation is a small issue. I have no problem fixing up my code to
the community's liking.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
