Type hinting - Request for Discussion

Hi Zeev,

I've been keeping a very close eye, and have taken part in a good few
discussions, including putting my own idea on the table.

The options as I see them:

1.  Do nothing.  I think the vote established that this is not what people
   want.

Agreed.

2.  Move forward with the semantics of the current patch.  This approach has
   substantial drawbacks in my opinion, and is a strong misfit with the rest of
   PHP (again, in my opinion).  See previous posts from Stas, Rasmus, myself
   and maybe others illustrating this point.  Lukas's 'Strict and Weak Typing
   RFC' (http://wiki.php.net/rfc/typecheckingstrictandweak) has some good
   insight as to why strict typing is problematic in PHP.

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.

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).

3.  Implement 'weak' typing.  What does that mean?  Conversion rules will be
   very similar to those for internal functions, but slightly stricter (like I
   said, if we were to rewrite the conversion rules for internal functions
   today - we'd probably make them slightly stricter, too).  For example, if
   you denote that an argument is supposed to be an integer, then a string that
   looks like an integer (e.g. "17") would be silently converted to an integer,
   however, a string that does not look like an integer (e.g. "foo") will error
   out.  We need to come up with a complete pass/fail table, but that would be
   the theme.  Unlike option #2, this fits the rest of PHP quite well (except
   for minor inconsistencies with internal functions - but these are dwarfed in
   comparison to the inconsistencies of option #2).

This seems like a good idea, but others disagree. I wrote a set of
rules for this, which are very much how you describe them: slightly
stricter than casting, but weaker than strict typing. In the
discussion, there was very little support, and so I withdrew it.

Two other issues that we need to revisit:

1.  Agree on when it will be implemented - I think it's pretty clear it
   should not go to 5.3.

The last discussion certainly made this clear. It should be cleared up
whether people want this is 5.4 (if it happens). I think its
established that people want this in 6.

2.  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.

Before moving ahead with votes or committing the code, I suggest we focus on
the pros & cons of options #2 and #3.  Since the inconsistencies introduced
by option #2 are very substantial (between internal and userland functions,
and also how values behave in PHP in general), I suggest we focus on use
cases where option #2 would be truly needed and superior to option #3.  In
other words - what is the added value and is it worth the price?

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

Indeed this adds the ability to make your function work like an
internals function (useful perhaps for library interfaces).

I think we can take Lukas's RFC and either change it or write something
based on it for weak typing only.  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.

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.

Obviously I'm not against discussion, but we just had this discussion.

Thanks,
Paul

--
Paul Biggar
paul.biggar@gmail.com

2009/7/9 Zeev Suraski zeev@zend.com:

Two other issues that we need to revisit:

1.  Agree on when it will be implemented - I think it's pretty clear it
   should not go to 5.3.

What would be the impact including this feature (once it is
technically fine for everybody) in 5.3 code with #ifdef's so that
this feature is enabled only at ./configure time and disabled by
default.

We could then imagine to switch this configure parameter as enabled by
default in a future (major) release.

This way, every vanilla PHP installation wouldn't suffer of BC
problems while still providing the feature to a restricted set of
users.

--
Patrick Allaert

http://code.google.com/p/peclapm/ - Alternative PHP Monitor

Hi!
I am a userland developer, so please take my advice with caution. I am not
aware of the consequences of any of the implementations from an internals
point of view. However, since the main question here seems to be strict
against weak typing, or casting, I feel I should voice my opinion.

From a user perspective, I feel that PHP does a very good job at casting
variables if needed. One should take care not to do anything stupid but
heh, that's programming... I therefore think using rules similar to the
casting rules is a good suggestion. It is easy to understand, easy to use
as a library developer and mostly, it is very easy to use for library users
(no change is needed to their code).

A function might look like this in PHP <= 5.3.0:
function foo ($x) {
return $x + 5; // hoping the user sends a numeric value, else the results
will be silently wrong
}

It could be used like this:
foo(5); // ok
foo('hello'); // wrong but no error
foo(fopen('hello')); // wrong but no error
foo(new CustomClass()); // wrong but no error

Or it could be written to check the type of the parameter:
function foo ($x) {
$y = (float) $x; // explicit cast
return $y + 5; // we know what type we have so we know the operation is
safe, we don't need any errors to be shown
}

The problem, as everyone is well aware, is that we need either to change the
value of $x (which I believe is bad practice) or to have a copy of $x cast
into $y, which of course means performance decrease and increased memory
consumption.

So, we all agree PHP should provide means to help developers simplify the
validation chain: type hinting (ie. telling the developer the parameters
should be converted before calling the function) or casting (ie. following
specific rules to cast to the right type).

With strong type hinting, the function would become:
function foo (float $x) { // if the user does not send a float value, the
function fails
echo $x + 5;
}

It could be used like this:
foo(5); // some kind of explicit error
foo((float) 5); // ok
foo(5.0); // ok
foo('hello'); // some kind of explicit error
foo((float) 'hello'); // wrong but that much is plain
foo(fopen('hello')); // some kind of explicit error
foo((float) fopen('hello')); // wrong but that much is plain
foo(new CustomClass()); // some kind of explicit error
foo((float) new CustomClass()); // wrong but that much is plain

We all agree, I hope, that this makes userland code very ugly, not to
mention very repetitive. Each time I call foo(), PHP would make me write a
manual cast on the parameters every time I call the function. I am quite
sure it helps to make the code a lot safer, but this is not at all what PHP
developers are used to do. And it would not help PHP's fame. To a user,
that would make PHP close to C or C++, but without the good performance. I
can see very little gain here.

Here is another example:
foo($var);

If I am not sure what type $var is at the time I call foo(), because this is
PHP and I have never had to worry about it before, strong type hinting would
have me do this:
foo((float) $var);

If I did that, my users would simply drop my libraries because they would
not appear to be written in PHP. Not the PHP they like, anyway. After all,
why would my libraries refuse an integer value when they expect a float?
And of course, PHP already has internal rules to convert several types to
others. Why not use that?

So, let's take a user point of view. As such, I defnitely would like to be
able to call my function foo() without any explicit casting every time I
need the function, under the threat that I would have errors when PHP should
already be able to cast the parameters.

foo(5); // ok
foo('hello'); // ok, empty
foo(fopen('hello')); // ok, could be empty or cast to: "0" for error, "1"
otherwise (like booleans in other languages)
foo(new CustomClass()); // ok, empty or maybe a handler can be set to
automatically cast in this case?

Of course, these are set values. Day to day programming does not always
involve hard-coded values like this but rather user-supplied values, ie.
mostly text values. I my experience, most of the time text values are easy
to cast to other types. I think this is why type hinting/casting could be
of great help.

Maybe a nice addition would be a specific error level so that I could see
where in my code these silent castings should take place. Or where they do
take place. Or neither.

foo($bar); // throws an error only if error_level is set to E_HINT

Bottom line: As a user of libraries, I see no good in strong hint typing.
However, as a library developer I see uses for it.

Best regards,

--
Guillaume Rossolini

hi,

I'm still in favour of #2 (Ilia's patch) as I don't see a real benefit
of a weak typing implementation, it defeats the main goal of this
addition. I'm also still opposed to add such thing in 5.3.x.

Cheers,

2.  Move forward with the semantics of the current patch.  This approach has
   substantial drawbacks in my opinion, and is a strong misfit with the rest of
   PHP (again, in my opinion).  See previous posts from Stas, Rasmus, myself
   and maybe others illustrating this point.  Lukas's 'Strict and Weak Typing
   RFC' (http://wiki.php.net/rfc/typecheckingstrictandweak) has some good
   insight as to why strict typing is problematic in PHP.

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

Le Fri, 10 Jul 2009 16:16:51 +0100, Alain Williams a écrit :

Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit :

And Exception is better than an Error because this give one chance
to
programmer for resolving the problem before program be halted.

Not everyone understands try/catch. Perhaps a user supplied
function_argument_error() could be called if not in a try/catch
block.

If user not understand try/catch, he don't use it and the exception,
not
catched, generate an error.

I think anybody who is coding with strict/weak/contract
type-enforcement/casting is going to understand
try/catch/Exceptions...

Granted, the people using that code and maybe stuck maintaining it
could be in for a steep learning curve.

But I don't think an Exception being thrown will be problematic for
the original coder using this type-hinting stuff.

PS
The contract stuff looks kind of cool, but seems too unwieldy for
pre-parsers/IDEs/lint type tools, so I'd have to vote "nay" on it, if
my svn access to docs gives me a vote...

--
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch