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.
-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.
>
> 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.
>
> 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.
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
