Re: [PHP-DEV] Type hinting - Request for Discussion
This sounds very similar to preconditions in Design by Contract. However,
preconditions validate input to the method as a whole, while the proposed
syntax only checks individual arguments one at a time. Thus the proposed
syntax has rather significan limitations compared to real preconditions.
For example, you could use preconditions to check whether a substring($str,
$from, $to) call has valid parameters. The check would look like this:
assert( $to strlen($str) )
However, there is no way to do this without looking at _both_ $str and $to
at the same time.
What I'm saying is, if people are willing to go as far as checking
individual parameters with userland functions, maybe there should be a
serious discussion on introducing proper preconditions into the language?
They are a tremendously useful tool for catching various bugs, and they
would solve the type-checking problem as well.
Giovanni Giacobbi giova...@giacobbi.net wrote in message
news:20090710144118.gd20...@gerbil.thgnet.it...
On Fri, Jul 10, 2009 at 01:40:47PM +0200, Lukas Kahwe Smith wrote:
On 10.07.2009, at 13:20, Lewis Wright wrote:
3) function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer
much more
useful than just calling the is_numeric method in the function body.
Plus
there's no longer the advantage of optimisers knowing the data-type.
right .. lets not forget the original goal (though it hasnt been
perfectly defined)
the idea was to move common validation code out of the function body
to reduce code, increase readability and enable IDE's to be even
smarter.
moving the function body into the signature was not the plan, as it
will kill the above features for the sake of flexibility.
the point is not flexibility, its finding a sensible common
denominator for validation of input parameters and optimizing the
syntax for that case.
Well actually I think the idea was to REPLACE the current syntax with the
contract specification, because it includes both the strict and weak typing,
plus it adds a powerful extensibility to the type checking system to user
space.
Also, we are not moving the function body into the signature, because it's
not a statement but a specific single function call.
The grammar will be very strict about what goes inside the signature: at
most one single function name, followed by any number of arguments which can
either be a $var, or a constant but NOT an expression. It should be possible
also to use another syntax:
function ContractHint(is_int:$a, $b, is_multiple:$c:5) { ... }
but I prefer the normal notation:
function ContractHint(is_int($a), $b, is_multiple($c, 5)) { ... }
They look like function calls, but they are NOT function calls in fact.
The executor will call them for each parameter, checking the (bool) returned
value and raising a detailed error with the current line where the type
checked function is called.
If you write your own checking code, raising an error with
trigger_error(), the error line reported will be inside the type checked
function, which is not very helpful for debugging (in fact I always have to
debug_backtrace() to find something useful).
There is NO ambiguity with current type hinting, you can still have
classes with the same name:
class is_int { }
function StandardHint(is_int $a);
IDEs can still act smart because is_int() is a PHP standard function, and
we could add a few more like cast_int(), and is_int_null().
--
Giovanni Giacobbi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Fri, July 10, 2009 10:50 am, Alban wrote: Le Fri, 10 Jul 2009 16:16:51 +0100, Alain Williams a écrit : On Fri, Jul 10, 2009 at 10:57:22AM -0400, Alban wrote: Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit : On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Tue, July 21, 2009 11:22 am, Christian Schneider wrote: Richard Lynch wrote: I think anybody who is coding with strict/weak/contract type-enforcement/casting is going to understand try/catch/Exceptions... I'm not going to start an pro/contra Exceptions rant but *please* keep Exceptions out of the core language itself, that's a line we should not cross IMHO... This posting is mainly for the record (currently there is an agreement to not use Exceptions inside the core and I'm in favour of this) and anyone who wants to discuss Exceptions with me should do it off list, I will not discuss this here ;-) I apologize. Elsewhere it was stated that they were to be kept to a minimum. If they are out entirely, by all means, keep it that way. I am not a fan of Exceptions myself. Integrating with a badly-written exception-based library is even worse than integrating with a badly-written error-messaging library. If the library is well-written, either works equally well. :-) -- Some people ask for gifts here. I just want you to buy an Indie CD for yourself: http://cdbaby.com/search/from/lynch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Richard Lynch wrote: I think anybody who is coding with strict/weak/contract type-enforcement/casting is going to understand try/catch/Exceptions... I'm not going to start an pro/contra Exceptions rant but *please* keep Exceptions out of the core language itself, that's a line we should not cross IMHO... This posting is mainly for the record (currently there is an agreement to not use Exceptions inside the core and I'm in favour of this) and anyone who wants to discuss Exceptions with me should do it off list, I will not discuss this here ;-) - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
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, On Thu, Jul 9, 2009 at 9:47 AM, Zeev Suraskiz...@zend.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
function addFive(is_numeric $x) {
return $x + 5;
}
Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.
Please let me state that this is the greatest idea I read since the type
hinting discussion began (and the only one I personally like, as I find all the
other proposals really disappointing).
I'd like to see some real debating about this syntax proposed by troels:
function addFive(is_numeric($x)) {
...
}
Because I really like the idea of passing other parameters:
function check_multiple($a, $b) {
return !($a % $b);
}
function doSomething(check_multiple($a, 3)) {
// assume that $a is a multiple of 3
}
This solves all the problems I've understood so far:
- BC breaks for new reserved keywords 'int', 'float', ...: there is no need for
them anymore
- weak typing vs strict typing:
function cast_bool($value) { $value = (bool) $value; return true; }
function weak_type_hinted(cast_bool($a)) { /* assume that $a is bool, no
fatal errors */ }
- Nullable values:
function is_int_nullable($val) { return is_int($val) || is_null($val); }
function int_or_null(is_int_nullable($a)) { /* either $a is int or it's
null */ }
- This will also make the error handling consistent where the classic type
hinting wouldn't cover a particular use case:
function foo(int $a) { ... }
function bar($b) {
if ($b is not appropriated parameter)
trigger_error(Invalid parameter);
}
// a type of error (E_RECOVERABLE or TypeCheckException or whatever)
foo(inappropriate_parameter);
// a custom error, which might be *slightly different* from the one generated
by the inner php engine
bar(another_inappropriate_parameter);
I think this gives the perfect freedom to the developers and makes everyone
happy. I know your concerns about third party libraries that you might have to
deal with, but if you trigger one of those errors, then it means you are not
respecting the APIs, which means there is a bug in your application.
--
Giovanni Giacobbi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 7/10/2009 13:23, Giovanni Giacobbi wrote:
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
function addFive(is_numeric $x) {
return $x + 5;
}
Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.
I like it too. Not only it solves the initial problem, but it also
allows userland extensions. For example,
the current patch does not provide checks for callables, but we already
have is_callable in the core.
--
Ionut G. Stan
I'm under construction | http://igstan.blogspot.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
2009/7/10 Ionut G. Stan ionut.g.s...@gmail.com
On 7/10/2009 13:23, Giovanni Giacobbi wrote:
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
function addFive(is_numeric $x) {
return $x + 5;
}
Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.
I like it too. Not only it solves the initial problem, but it also allows
userland extensions. For example,
the current patch does not provide checks for callables, but we already
have is_callable in the core.
But isn't is_numeric still a valid class name? Would that mean that classes
could no longer be called is_*?
Re: [PHP-DEV] Type hinting - Request for Discussion
On Fri, Jul 10, 2009 at 01:35:45PM +0300, Ionut G. Stan wrote:
On 7/10/2009 13:23, Giovanni Giacobbi wrote:
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
function addFive(is_numeric $x) {
return $x + 5;
}
Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.
I like it too. Not only it solves the initial problem, but it also
allows userland extensions. For example,
the current patch does not provide checks for callables, but we already
have is_callable in the core.
Hmmm, but it makes simple cases more complicated and slower. But I do like the
idea of generalising it with a function to handle 'strange' cases.
So, we have 3 syntaxes:
1) function Foo(int $x) {
$x is tested to be integer, if it isn't an error is raised - either by
exception
or just a fatal error.
A problem with this is that it could yeild some surprising results, eg:
Foo(4/2); -- OK
Foo(4/3); -- FAIL since 4/3 yeilds a float
In this last case people would learn to:
Foo((int)(4/3));
2) function Foo((int) $x) {
$x is cast to int, ie converted iff possible - otherwise an error is raised:
int - int -- OK
float - int -- OK if in the range for integer
string - int -- OK iff it is 100% clean:
'10' - OK
'10.1' - OK as string - float - int
'10ten' - FAIL/ERROR
etc
What happens when someone tries to use this syntax where he is casting to an
object ?
I suggest that this fails unless the object has a __cast method, in which
case that is invoked:
function Foo((MyObject) $x) {
...
}
class MyObject {
function __cast($x) {
if( . )
return new Foo('abcd', $x);
}
...
}
3) function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
2009/7/10 Alain Williams a...@phcomp.co.uk
On Fri, Jul 10, 2009 at 01:35:45PM +0300, Ionut G. Stan wrote:
On 7/10/2009 13:23, Giovanni Giacobbi wrote:
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
function addFive(is_numeric $x) {
return $x + 5;
}
Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.
I like it too. Not only it solves the initial problem, but it also
allows userland extensions. For example,
the current patch does not provide checks for callables, but we already
have is_callable in the core.
Hmmm, but it makes simple cases more complicated and slower. But I do like
the
idea of generalising it with a function to handle 'strange' cases.
So, we have 3 syntaxes:
1) function Foo(int $x) {
$x is tested to be integer, if it isn't an error is raised - either by
exception
or just a fatal error.
A problem with this is that it could yeild some surprising results, eg:
Foo(4/2); -- OK
Foo(4/3); -- FAIL since 4/3 yeilds a float
In this last case people would learn to:
Foo((int)(4/3));
2) function Foo((int) $x) {
$x is cast to int, ie converted iff possible - otherwise an error is
raised:
int - int -- OK
float - int -- OK if in the range for integer
string - int -- OK iff it is 100% clean:
'10' - OK
'10.1' - OK as string - float - int
'10ten' - FAIL/ERROR
etc
What happens when someone tries to use this syntax where he is casting to
an object ?
I suggest that this fails unless the object has a __cast method, in which
case that is invoked:
function Foo((MyObject) $x) {
...
}
class MyObject {
function __cast($x) {
if( . )
return new Foo('abcd', $x);
}
...
}
3) function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer much more
useful than just calling the is_numeric method in the function body. Plus
there's no longer the advantage of optimisers knowing the data-type.
Lewis.
Re: [PHP-DEV] Type hinting - Request for Discussion
On 10.07.2009, at 13:20, Lewis Wright wrote:
3) function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer
much more
useful than just calling the is_numeric method in the function body.
Plus
there's no longer the advantage of optimisers knowing the data-type.
right .. lets not forget the original goal (though it hasnt been
perfectly defined)
the idea was to move common validation code out of the function body
to reduce code, increase readability and enable IDE's to be even
smarter.
moving the function body into the signature was not the plan, as it
will kill the above features for the sake of flexibility.
the point is not flexibility, its finding a sensible common
denominator for validation of input parameters and optimizing the
syntax for that case.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Le Thu, 09 Jul 2009 21:11:31 +0200, Geoffrey Sneddon a écrit : On 9 Jul 2009, at 18:20, Lukas Kahwe Smith wrote: On 09.07.2009, at 10:39, Paul Biggar wrote: 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. Actually, in terms of weak typing we are now at 4 supporters of the general idea: Paul B., Lukas, Zeev, Christian S. As I said in the other thread, I'm in favour of weak typing (and against strict typing). -g Hello all, I don't understand why you focus on Strict / Weak question. For me it's very simple, it's not obligatory use Type Hiting. Developpers wants to write a weak code, they'll just have to not use Type Hiting and developpers wants wrote a stric code they'll have to use it. After, choosing use or not Type Hinting when writing a librairy / framework, this is not a php.internal problem. It's a developper, designer, marketing choice ! Use or not use Type hiting can help to chose a user target. And if you want be just between weak and strict, numeric and scalar type hiting seems to be a very good middle point. +1 for Strict type hiting. (weak type hiting very similar to no type hiting). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote: Hello all, I don't understand why you focus on Strict / Weak question. It is really about: * type checking and enforcement or * type casting and generation of an error if the value cannot be converted cleanly Both of these have a value in different situations ... I would like to see both. The option of no checking/casting (as at present) should remain. For me it's very simple, it's not obligatory use Type Hiting. Developpers wants to write a weak code, they'll just have to not use Type Hiting and developpers wants wrote a stric code they'll have to use it. After, choosing use or not Type Hinting when writing a librairy / framework, this is not a php.internal problem. It's a developper, designer, marketing choice ! Use or not use Type hiting can help to chose a user target. And if you want be just between weak and strict, numeric and scalar type hiting seems to be a very good middle point. +1 for Strict type hiting. (weak type hiting very similar to no type hiting). -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Please let me state that this is the greatest idea I read since the type hinting discussion began (and the only one I personally like, as I find all the other proposals really disappointing). +1. This contract system seems to be the best by far. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 10.07.2009, at 13:20, Lewis Wright wrote:
3) function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer
much more
useful than just calling the is_numeric method in the function body.
Plus
there's no longer the advantage of optimisers knowing the data-type.
right .. lets not forget the original goal (though it hasnt been
perfectly defined)
the idea was to move common validation code out of the function body
to reduce code, increase readability and enable IDE's to be even
smarter.
moving the function body into the signature was not the plan, as it
will kill the above features for the sake of flexibility.
the point is not flexibility, its finding a sensible common
denominator for validation of input parameters and optimizing the
syntax for that case.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
I don't believe it kills the above features.
1) Move common validation code out of the function body to reduce code
This option moves the validation code out of the body and reduces the
amount of code. PHP does the error checking instead of the user having
to do something like:
?php
function test($x)
{
if (!is_numeric($x)) {
trigger_error(...);
}
...
}
2) Increase readability
If is_numeric($x) is in the method signature, then obviously $x needs to
be numeric. Now of course userland code can abuse this, but that is
nothing new for PHP.
3) Enable IDEs to be even smarter
For the internal functions, this should be very easy for an IDE to
figure out: simply remove the is_ from the beginning of the function and
you get the desired type. It can then display the method signature and
even verify the type supplied. It could also do the same for the
userland functions.
There may be problems with the contracts idea, but I just don't think
these are very convincing arguments against it.
--
Joshua Thompson
Mechanical Engineer/Software Developer
http://www.schmalls.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Alban wrote: I don't understand why you focus on Strict / Weak question. For me it's very simple, it's not obligatory use Type Hiting. Developpers wants to write a weak code, they'll just have to not use Type Hiting and developpers wants wrote a stric code they'll have to use it. After, choosing use or not Type Hinting when writing a librairy / framework, this is not a php.internal problem. It's a developper, designer, marketing choice ! Use or not use Type hiting can help to chose a user target. And if you want be just between weak and strict, numeric and scalar type hiting seems to be a very good middle point. +1 for Strict type hiting. (weak type hiting very similar to no type hiting). I was just going to send something like this. Big +1 to this comment. Just add type hinting (strict) and type casting (weak). It is up to the developer to use either or none. Strict should be strict, if the user wants float, the user get's float. That's the way class/array type hinting works now.. Use the type casting option if they want int to float. Things such as is_numeric or just numeric would be nice but could be added later if need be. Weak does have some questions around it, no argument there. But IMO just make it work simplistically for now and add additional features later. Some things won't work at the beginning so just document that. Ex: an object can't be casted to anything other than string at this point. And cast an object to another object.. Couple features would be a nice addition to support this, __cast() and __box() __unbox(), but I doubt it will be added at the same time. Unless effort is put forward for everything in a 5.4 release, or wait for 6.0 (way to far out though). Error handling I'm not sure about though. Should it be a error or exception, not sure. I'd say if possible, if a function an error would work, if a class method throw an exception. Just don't know though. As far as the discussion about if it's added then everyone will have to use the feature, no choice, it'll show up at some point. That is up to the projects code guidelines. If you're that concerned then it's up to the manager to enforce the no use of the feature. /End -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Fri, Jul 10, 2009 at 01:40:47PM +0200, Lukas Kahwe Smith wrote:
On 10.07.2009, at 13:20, Lewis Wright wrote:
3) function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer
much more
useful than just calling the is_numeric method in the function body.
Plus
there's no longer the advantage of optimisers knowing the data-type.
right .. lets not forget the original goal (though it hasnt been
perfectly defined)
the idea was to move common validation code out of the function body
to reduce code, increase readability and enable IDE's to be even
smarter.
moving the function body into the signature was not the plan, as it
will kill the above features for the sake of flexibility.
the point is not flexibility, its finding a sensible common
denominator for validation of input parameters and optimizing the
syntax for that case.
Well actually I think the idea was to REPLACE the current syntax with the
contract specification, because it includes both the strict and weak typing,
plus it adds a powerful extensibility to the type checking system to user
space.
Also, we are not moving the function body into the signature, because it's not
a statement but a specific single function call.
The grammar will be very strict about what goes inside the signature: at most
one single function name, followed by any number of arguments which can either
be a $var, or a constant but NOT an expression. It should be possible also to
use another syntax:
function ContractHint(is_int:$a, $b, is_multiple:$c:5) { ... }
but I prefer the normal notation:
function ContractHint(is_int($a), $b, is_multiple($c, 5)) { ... }
They look like function calls, but they are NOT function calls in fact. The
executor will call them for each parameter, checking the (bool) returned value
and raising a detailed error with the current line where the type checked
function is called.
If you write your own checking code, raising an error with trigger_error(), the
error line reported will be inside the type checked function, which is not very
helpful for debugging (in fact I always have to debug_backtrace() to find
something useful).
There is NO ambiguity with current type hinting, you can still have classes
with the same name:
class is_int { }
function StandardHint(is_int $a);
IDEs can still act smart because is_int() is a PHP standard function, and we
could add a few more like cast_int(), and is_int_null().
--
Giovanni Giacobbi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Just to add a little fuel to this fire, should we allow the specification of
return
type of functions, eg:
function int Factorial(int $num) {...}
What about things that return FALSE on error, eg fgets(), something like this:
function (string, bool) fgets(resource $handle, int $length) { ... }
I suspect that it makes things too complicated.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit : On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote: Hello all, I don't understand why you focus on Strict / Weak question. It is really about: * type checking and enforcement or * type casting and generation of an error if the value cannot be converted cleanly Thank for your response ! I vote for throw an exception if data type won't match. Have one error when you make a mistake is better than have a silently casting which can transform your data in another form than what you want. And Exception is better than an Error because this give one chance to programmer for resolving the problem before program be halted. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
2009/7/10 Alain Williams a...@phcomp.co.uk:
Just to add a little fuel to this fire, should we allow the specification of
return
type of functions, eg:
function int Factorial(int $num) {...}
What about things that return FALSE on error, eg fgets(), something like this:
function (string, bool) fgets(resource $handle, int $length) { ... }
I suspect that it makes things too complicated.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
This would be the perfect pairing. A library utilizing strict/enforced
types would surely want to indicate explicitly the return type.
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Fri, Jul 10, 2009 at 10:57:22AM -0400, Alban wrote: Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit : On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote: Hello all, I don't understand why you focus on Strict / Weak question. It is really about: * type checking and enforcement or * type casting and generation of an error if the value cannot be converted cleanly Thank for your response ! I vote for throw an exception if data type won't match. Have one error when you make a mistake is better than have a silently casting which can transform your data in another form than what you want. I think that we need both. * Strict enforcement is useful. * Doing silent type casting can be useful, a naive example is: is_child($_GET['age']) The GET argument here should always be integer, however if it is in $_GET it will be a string. NB: I am not advocating the above to be a way of avoiding checking what there is in $_GET - however many PHP users will use it as such. If casting (with errors) help to avoid silent errors - then so much the better. 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. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 10.07.2009, at 17:16, Alain Williams a...@phcomp.co.uk wrote: On Fri, Jul 10, 2009 at 10:57:22AM -0400, Alban wrote: 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. well we have an recoverable error in this case which is what you are asking for. an exception could be more useful since you can handle it locally and are not forced to handle this inside a global error handler. then again we really wanted to keep internal exceptio. throwing to a minimum. regardgs lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
At 10:42 10/07/2009, Pierre Joye wrote: 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. Can you elaborate on what is the main goal of this addition that using weak-typing implementation instead would defeat? (with emphasis on use case(s) including both calling called code, otherwise we'd be back and forth on a matter of pure personal preference). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Le Fri, 10 Jul 2009 16:16:51 +0100, Alain Williams a écrit : On Fri, Jul 10, 2009 at 10:57:22AM -0400, Alban wrote: Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit : On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote: Hello all, I don't understand why you focus on Strict / Weak question. It is really about: * type checking and enforcement or * type casting and generation of an error if the value cannot be converted cleanly Thank for your response ! I vote for throw an exception if data type won't match. Have one error when you make a mistake is better than have a silently casting which can transform your data in another form than what you want. I think that we need both. * Strict enforcement is useful. * Doing silent type casting can be useful, a naive example is: is_child($_GET['age']) The GET argument here should always be integer, however if it is in $_GET it will be a string. NB: I am not advocating the above to be a way of avoiding checking what there is in $_GET - however many PHP users will use it as such. If casting (with errors) help to avoid silent errors - then so much the better. The GET argument, yes, should be an integer, but it's possible is not ! In this, actually i always use this syntaxe : is_child(intval($_GET['age'])); or is_child( (int) ($_GET['age'])); This a big precaution for security reason. And you say it below, many users don't check there $_GET and $_POST datas. Yes, casting could help us silently but, perhaps, this is not the better way for educating these users. And In this case especially, numeric type hiting work very fine. The question is who coded the is_child function ? 1. The use himself ? If he use the type hiting in is function, he know how use it. 2. It's a PHP core function ? The question is Type hiting or not in php core function ? (perhaps in this case I prefer silently casting) 3. It's made by a team developper. Working with a team, there is certainly some recommendation and guide line (include how to type hiting). 3. It's a downloaded librairie make by a third part ? This the third part choice, there is certainly a good raison to be strict (or bad, just for use type hiting for example). 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. Please, excuse my english, I'm very bad :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Fri, Jul 10, 2009 at 11:50:04AM -0400, Alban wrote: Le Fri, 10 Jul 2009 16:16:51 +0100, Alain Williams a écrit : The GET argument, yes, should be an integer, but it's possible is not ! In this, actually i always use this syntaxe : is_child(intval($_GET['age'])); or is_child( (int) ($_GET['age'])); *You* do the above because you know that you should; (hopefully you do other checks as well). One of the things that we are doing is trying to help the naive/lazy programmer who doesn't bother - or thinks that javascript checking is enough :-( What we want to do is to generate an error/warning message that can tell him that something is wrong. This a big precaution for security reason. And you say it below, many users don't check there $_GET and $_POST datas. Yes, casting could help us silently but, perhaps, this is not the better way for educating these users. The point is that casting MUST NOT be silent where a conversion is not clean. It must be stricter than the rules laid out at: http://uk3.php.net/manual/en/language.types.string.php#language.types.string.conversion This will not break BC compatability because no code currently uses a cast in a function argument where the cast is in the function definition. We would need to be clear that casting here is stricter than normal. And In this case especially, numeric type hiting work very fine. The question is who coded the is_child function ? It doesn't really matter who coded it. 1. The use himself ? If he use the type hiting in is function, he know how use it. 2. It's a PHP core function ? The question is Type hiting or not in php core function ? (perhaps in this case I prefer silently casting) 3. It's made by a team developper. Working with a team, there is certainly some recommendation and guide line (include how to type hiting). 3. It's a downloaded librairie make by a third part ? This the third part choice, there is certainly a good raison to be strict (or bad, just for use type hiting for example). Please, excuse my english, I'm very bad :) Don't worry - you message was well understood. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Fwd: [PHP-DEV] Type hinting - Request for Discussion
-- Forwarded message -- From: troels knak-nielsen troel...@gmail.com Date: Fri, Jul 10, 2009 at 2:12 PM Subject: Re: [PHP-DEV] Type hinting - Request for Discussion To: Lukas Kahwe Smith m...@pooteeweet.org On Fri, Jul 10, 2009 at 1:40 PM, Lukas Kahwe Smithm...@pooteeweet.org wrote: right .. lets not forget the original goal (though it hasnt been perfectly defined) Good point, clarifying the goal should probably have been done long time ago. I think that some of the reason why this discussion has fragmented and begun to go sour, is that it started with an implementation proposal - not with a problem to be solved. This makes it very hard to agree on anything or even to have a meaningful discussion. So you suggest the following goals: Move common validation code out of the function body in order to * reduce code * increase readability * enable IDE's to be even smarter. That sounds like a good proposal. Now, static typing is one possible solution to that. Contracts is another. I like contracts better, since they focus on the interface rather than on the implementation. I think this is much more in lieu with php's type system. I do agree that moving imperative code into the signature complicates matters and looks rather messy. I don't think that's the case as per my initial proposal however. Now, static typing does provide one benefit over a strictly run-time contract. It enables a more meaningful static analysis of the code. This translates into smarter IDE's and enables certain transformations of source code (Eg. automated refactoring). But they also come at a cost in flexibility, makes the language more verbose and even then, it will still only be a partial solution. Personally I just don't think this price is worth it, just to get smarter IDE's. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
*You* do the above because you know that you should; (hopefully you do other checks as well). One of the things that we are doing is trying to help the naive/lazy programmer who doesn't bother - or thinks that javascript checking is enough :-( What we want to do is to generate an error/warning message that can tell him that something is wrong. Bad programmers write bad code and will continue to do so irrespective of type hinting. Better documentation is the answer to that problem, not magic casting, IMHO. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Fwd: [PHP-DEV] Type hinting - Request for Discussion
On Fri, Jul 10, 2009 at 06:10:33PM +0200, troels knak-nielsen wrote: So you suggest the following goals: Move common validation code out of the function body in order to * reduce code * increase readability * enable IDE's to be even smarter. Also it will improve reflection, this could be good for things like generating a WSDL file... which currently works by parsing pseudo comments in the source. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Hi!
According to Zeev's description of the behavior this would cause a
fatal error, as $_GET['a'] cannot be converted to an integer value.. I
like that, but I think we need to devise a mechanism that allows you
to catch this error at runtime and write application logic around
it... In the simple case above the point would be to be able to catch
Well, we could make it E_RECOVERABLE_ERROR. But it's not customizable,
unfortunately. If you want graceful handling (like custom error
messages), I don't believe you can do it language-level. Use app-level
validators (like Zend_Validate in Zend Framework) for that.
the error so that the requesting user could be informed he must enter
two integer values. Off the top of my head the only mechanism that I
can think of would be to throw an exception, which I'm not crazy about
either:
try
{
print foo($_GET['a'], $_GET['b']);
} catch(TypeCheckException $e) {
print Sorry, you need to provide two integer values!;
}
If you're going to write specific code to catch specific exceptions, why
don't you just check for specific constraints? It's the same amount of
code, but done the right way - you say what you actually mean to do and
do not make validation an afterthought, and allows you to give the user
much better feedback (this field is wrong instead of some field is
wrong). And what happens to your code after you add one more value? I
think app-level validation mechanism would work much better in this case.
Personally I really like the practical feel and ease of understanding
of using an exception in this case, but the idea of an exception being
thrown from potentially procedural code isn't the best thing to me..
I think exception would be impractical in real user-facing code - it's
too generic to give useful information, and you will have to have
validation on top of that anyway (emails, html, whatever).
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Hi! right .. lets not forget the original goal (though it hasnt been perfectly defined) the idea was to move common validation code out of the function body to reduce code, increase readability and enable IDE's to be even smarter. I think while intent is good (avoiding repetitive code) the strict implementation would do exactly the opposite of what should be done - it would move the repeated validation from library code to client code. WHich would negatively influence both readability (in case you do it right) and code robustness (in case you forget to do the necessary checks). the point is not flexibility, its finding a sensible common denominator for validation of input parameters and optimizing the syntax for that case. Why the point can't be flexibility? And if we talk about common denominator, how many use cases must accept 1, but not '1' or '1.0'? How many use cases can accept float, but can't accept integer? How many use cases need boolean but can't accept 0? How many use cases need string, but should never accept object with working toString() like SimpleXML element? I don't see many such cases now. Do you? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Hi! This would be the perfect pairing. A library utilizing strict/enforced types would surely want to indicate explicitly the return type. To what use? PHP can't do static type checking, and for dynamic checking specifying the type is useless - it's zval that gets checked, not the specification. And a lot of functions now return something like object or false or string or false. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 10.07.2009, at 19:58, Stanislav Malyshev wrote: Hi! right .. lets not forget the original goal (though it hasnt been perfectly defined) the idea was to move common validation code out of the function body to reduce code, increase readability and enable IDE's to be even smarter. I think while intent is good (avoiding repetitive code) the strict implementation would do exactly the opposite of what should be done - it would move the repeated validation from library code to client code. WHich would negatively influence both readability (in case you do it right) and code robustness (in case you forget to do the necessary checks). +1 ... this is one of the key points i tried to make in my RFC. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Type hinting - Request for Discussion
All, I think that we should revisit the options on the table. I have a feeling that much like many people didn't realize they're voting to bring this into 5.3 - many weren't fully aware of the options on the table and their implications (to be clear - I'm sure some were, but I think many were not). The options as I see them: 1. Do nothing. I think the vote established that this is not what people want. 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. 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). 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. 2. Make sure people understand *why* we're implementing it - performance is certainly *not* the reason. 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? 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. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 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.
On Thu, Jul 9, 2009 at 8:47 AM, Zeev Suraskiz...@zend.com wrote:
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.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
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.
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.
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).
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.
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.
Maybe - but the only way to make sure is to make it a clear part of the RFC(s).
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
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.
Indeed this adds the ability to make your function work like an
internals function (useful perhaps for library interfaces).
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.
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.
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.
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.
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.
Obviously I'm not against discussion, but we just had this discussion.
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.
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?
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Thu, Jul 9, 2009 at 10:46 AM, Zeev Suraskiz...@zend.com wrote: 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. The two approaches were never compared head-to-head, with the pros and cons 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. the discussion missed key ingredients, we should discuss it further. I think you are right that the discussions weren't sufficiently clear, and this could be resolved by better RFCs. This is obviously how it should have been done in the first place (look at the success of Python's PEPs). I'm not sure this will change things, and worry it might derail what we have now, but those are not good reasons to stop the discussion. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting - Request for Discussion
-Oorspronkelijk bericht-
Van: Zeev Suraski [mailto:z...@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
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.
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.
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).
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.
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.
Maybe - but the only way to make sure is to make it a clear part of the
RFC(s).
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
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.
Indeed this adds the ability to make your function work like an
internals function (useful perhaps for library interfaces).
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.
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.
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.
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.
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.
Obviously I'm not against discussion, but we just had this discussion.
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.
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?
Zeev
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
Re: [PHP-DEV] Type hinting - Request for Discussion
Hi Dennis, On Thu, Jul 9, 2009 at 11:49 AM, Dennis Haarbrinkden...@born05.nl wrote: The most important thing is that it is _optional_, you have the _choice_ to use it. Sorry to go a little bit off-topic, but this idea has been bandied around a lot over the last week, and I'd like to respond to it. Although the proposed checks are optional, nobody has a _choice_ to use a new language feature. Though you may choose not to use a feature in your code for whatever reason, it will appear in code from your colleagues, clients, or upstream libraries. Every feature in PHP will at some point be put in front of every PHP developer. As a result, the argument that you dont like it, so what, you have a choice not to use it, is simply incorrect. Though at some point the majority may have to overrule the views of the minority, please do not dismiss them out of hand with this logic. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
2009/7/9 Zeev Suraski z...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 09.07.2009, at 13:10, Patrick ALLAERT wrote: 2009/7/9 Zeev Suraski z...@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. thats a no go, since this would lead to incompatible PHP code. we have had various php.ini settings that have caused this and we do not want to pile onto this. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 09.07.2009, at 12:49, Dennis Haarbrink wrote: 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. I think you misunderstood Zeev. He wasn't saying that this feature is not PHP-ish, he was specifically talking about strict type checking. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Thu, Jul 9, 2009 at 1:33 PM, Dennis Haarbrinkden...@born05.nl wrote: I mean, libraries may have all kinds of quirks, you may not be satisfied with the supplied API or maybe even the entire philosophy behind it, but that shouldn't stop you from using it or is it? You must learn what these quirks are. Likewise, every developer must learn the quirks of the type hinting as they will almost certainly be required to interact with code that uses it. In an extreme case, suppose that we completely balls-ed up the semantics of type checks to be really really hard to use, but people used them anyway. That would lead to a sharp learning curve. The people who are against this proposal, or any other, know they will be required to use it when it comes in, and have an interest in making sure it is clean (whatever that means in each case). We shouldn't dismiss their objections on the argument that they arent required to use it. If its in the language, they are required to learn it. Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting - Request for Discussion
Hi Paul, -Oorspronkelijk bericht- Van: Paul Biggar [mailto:paul.big...@gmail.com] Verzonden: donderdag 9 juli 2009 13:03 Aan: Dennis Haarbrink CC: internals@lists.php.net Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion Although the proposed checks are optional, nobody has a _choice_ to use a new language feature. Though you may choose not to use a feature in your code for whatever reason, it will appear in code from your colleagues, clients, or upstream libraries. Every feature in PHP will at some point be put in front of every PHP developer. I don't think this is a really valid argument. I mean, libraries may have all kinds of quirks, you may not be satisfied with the supplied API or maybe even the entire philosophy behind it, but that shouldn't stop you from using it or is it? Regards, Dennis Haarbrink -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Zeev Suraski wrote: We need to go back to the fundamentals - and look for use cases where strict typing would be substantially superior to weak typing. I whole-heartedly agree. I can see some benefits of having weak typing (even though I'm not desperate for it) and think it would better fit PHP than strict typing. If someone brings up real world use cases for strict typing then please not only include the function being called but also the calling code as in my experience that's where the type juggling will happen once you have strict typing. And that's where weak typing could shine IMHO. Regards, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting - Request for Discussion
Lukas, -Oorspronkelijk bericht- Van: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] Verzonden: donderdag 9 juli 2009 14:01 Aan: Dennis Haarbrink CC: internals@lists.php.net Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion I think you misunderstood Zeev. He wasn't saying that this feature is not PHP-ish, he was specifically talking about strict type checking. regards, Lukas Kahwe Smith m...@pooteeweet.org Although I replied to Zeev's message it was more of a general observation than directly aimed at him. Regards, Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting - Request for Discussion
-Oorspronkelijk bericht- Van: Paul Biggar [mailto:paul.big...@gmail.com] Verzonden: donderdag 9 juli 2009 14:40 Aan: Dennis Haarbrink CC: internals@lists.php.net Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion You must learn what these quirks are. Likewise, every developer must learn the quirks of the type hinting as they will almost certainly be required to interact with code that uses it. In an extreme case, suppose that we completely balls-ed up the semantics of type checks to be really really hard to use, but people used them anyway. That would lead to a sharp learning curve. The people who are against this proposal, or any other, know they will be required to use it when it comes in, and have an interest in making sure it is clean (whatever that means in each case). We shouldn't dismiss their objections on the argument that they arent required to use it. If its in the language, they are required to learn it. Paul -- Paul Biggar paul.big...@gmail.com Thanks for this elaboration, I totally see your point. Regards, Dennis Haarbrink -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 09.07.2009, at 10:39, Paul Biggar wrote: 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. Actually, in terms of weak typing we are now at 4 supporters of the general idea: Paul B., Lukas, Zeev, Christian S. Still a minority compared to the +1 votes for Ilia's strict typing proposal. Though it could be argued that a fair number only voted for the expansion of type hinting to scalar datatypes and did not really look into the entire strict vs. weak hinting stuff. regards Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Thu, Jul 9, 2009 at 5:20 PM, Lukas Kahwe Smithm...@pooteeweet.org wrote: Actually, in terms of weak typing we are now at 4 supporters of the general idea: Paul B., Better make that 3 supporters. After seeing how complicated it was to explain the semantics of a sensible middle, I think the patch that Ilia currently has is close to ideal (the strict semantics are trivial to understand, the weak ones are the same as whats already here). Naturally, I might change my position upon seeing the new RFCs. Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
I want to remind everyone that this discussion is inadvertently sabotaging the work/schedule of maintenance 5.3.x point releases, which we actually need, for the 5.3 branch get to a point where it's stable enough to be used in production. So, knowing this can go on forever, it's time to pick which you want first: A) Stable 5.3 with namespaces, closures, late static binding, phar, SPL additions and more (essential brand new functionality, feature complete, only needs bug fixes). B) Strict type casts/hints (shortcut for existing is_*() / cast functionality). Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Hi list.
In advance, sorry for muddying the waters even further.
Following the current discussion about typehints to primitives, I'm
wondering if anyone have ever suggested to include some sort of
user-land contract system, such as the one that exists in
plt-scheme[1]
Given the dynamic nature of php, I would suspect that it might be a
much better fit. Unlike the semi-static typecheck that typehints can
give, a contract system would be much more expressive and would add a
lot more value (in my opinion anyway).
I think part of the reason for the popularity of typehints is that it
looks familiar for people coming from Java/C++/C#. The biggest
challenge for such a contract system would then be to come up with
something that doesn't look too alien. A simple way that I can think
of is to overload the meaning of typehints so that they may either
denote a class/interface (as they work currently) OR they may be a
function which takes the variable as argument and yields a boolean.
Eg.:
function array_of_numeric($x) {
foreach ($x as $val) {
if (!is_numeric($val)) {
return false;
}
}
return true;
}
class Foo {
/** Example use-case for a contract */
function sum(array_of_numeric $a) {
return array_sum($a);
}
}
This is just one suggestion - There are other ways to implement the concept.
I can see a number of benefits to a contract system over the currently
discussed typehint system:
1) It covers all the use cases for a type-based system (You can use
`is_integer` as a contract, if you want that)
2) It's extensible in user-space, which means that it can be used to
convey much more accurate information, relevant to the application
needs.
3) It's focused on the interface of input-parameters, rather than their type.
[1] http://docs.plt-scheme.org/guide/contracts.html
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Hi! Actually, in terms of weak typing we are now at 4 supporters of the general idea: Count me in, then :) -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 9 Jul 2009, at 18:20, Lukas Kahwe Smith wrote: On 09.07.2009, at 10:39, Paul Biggar wrote: 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. Actually, in terms of weak typing we are now at 4 supporters of the general idea: Paul B., Lukas, Zeev, Christian S. As I said in the other thread, I'm in favour of weak typing (and against strict typing). -g -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
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
Re: [PHP-DEV] Type hinting - Request for Discussion
troels knak-nielsen wrote:
1) It covers all the use cases for a type-based system (You can use
`is_integer` as a contract, if you want that)
2) It's extensible in user-space, which means that it can be used to
convey much more accurate information, relevant to the application
needs.
3) It's focused on the interface of input-parameters, rather than their type.
This is my favorite alternative so far. There are just a few problems
with parsing as I see it.
- How do you know if it is a contract or the current object type hint?
- It doesn't allow a type to be forced (casted) to the correct type.
To address these items, I suggest the following changes.
Change the syntax of the contract to look like a function call (which is
essentially what we are doing):
?php
function array_of_numeric($x)
{
if (!is_array($x)) {
return false;
}
foreach ($x as $val) {
if (!is_numeric($val)) {
return false;
}
}
return true;
}
function sum(array_of_numeric($a)) {
return array_sum($a);
}
This could even be extended to allow for more generic types by allowing
constant parameters for the contract:
?php
function array_of($x, $type)
{
if (!is_array($x)) {
return false;
}
switch ($type) {
case 'int':
$check = 'is_int';
break;
case 'float':
$check = 'is_float';
break;
case 'numeric':
$check = 'is_numeric';
break;
case 'string':
$check = 'is_string';
break;
case 'bool':
$check = 'is_bool';
break;
default:
return false;
}
foreach ($x as $val) {
if (!$check($val)) {
return false;
}
}
return true;
}
function sum(array_of($a, 'numeric')) {
return array_sum($a);
}
To allow for casting, the contract function could take the value by
reference and cast it:
?php
function array_of_float($x)
{
if (!is_array($x)) {
return false;
}
foreach ($x as $key = $val) {
if (!is_numeric($val)) {
return false;
}
$x[$key] = (float)$val;
}
return true;
}
function sum(array_of_float($a)) {
return array_sum($a);
}
--
Joshua Thompson
Mechanical Engineer/Software Developer
http://www.schmalls.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Fri, Jul 10, 2009 at 2:28 AM, Josh
Thompsonspam.goes.in.h...@gmail.com wrote:
troels knak-nielsen wrote:
- How do you know if it is a contract or the current object type hint?
The simplest solution would be to make one take precedence. You're not
likely to have both a class and a function with the same name, and if
you do, you kind of had it coming to you. For backwards compatibility
it would probably be most fitting to let the current behaviour
(class/interface) take precedence, although the other way around makes
for some quite interesting possibilities.
- It doesn't allow a type to be forced (casted) to the correct type.
As far as I can tell, this is a moot point. The whole discussion about
casting comes from the fact that hinting to a primitive type is more
restrictive than php's weak typing system. With a contract system this
problem doesn't exist. You could test that something conforms to your
specifications and then simply let the type system do its thing.
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
function addFive(is_numeric $x) {
return $x + 5;
}
Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
troels knak-nielsen wrote: - How do you know if it is a contract or the current object type hint? The simplest solution would be to make one take precedence. You're not likely to have both a class and a function with the same name, and if you do, you kind of had it coming to you. For backwards compatibility it would probably be most fitting to let the current behaviour (class/interface) take precedence, although the other way around makes for some quite interesting possibilities. I would much rather be explicit with a different syntax, that way we don't have to add a new set of resolution rules. For example what would this do to autoload? Would we have to call it to see if the class is available every time? I think the function syntax disambiguates things and hints at what is happening. - It doesn't allow a type to be forced (casted) to the correct type. As far as I can tell, this is a moot point. The whole discussion about casting comes from the fact that hinting to a primitive type is more restrictive than php's weak typing system. With a contract system this problem doesn't exist. You could test that something conforms to your specifications and then simply let the type system do its thing. I can concede on this point. I just thought there might be some reason you would need it in a specific type, but none are coming to mind... -- Joshua Thompson Mechanical Engineer/Software Developer http://www.schmalls.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
All:
I'm in favor of this so-called Weak typing Zeev has proposed as
well, but I would like to see it become available in PHP before PHP 6.
That doesn't mean it has to go into 5.3.x, but I don't see why there
can't be a 5.4 that includes it. Personally, I think primitive typing
has a much more immediate need than many of the features proposed for
6 and, considering there is already been numerous working patches that
implement this feature in principal, I don't see why we can't have a
5.4 release including it. Waiting for PHP 6 is too long and the many
serious time-consuming tasks that are required to achieve the goals of
PHP 6 shouldn't stop a very useful feature like this from getting into
the wild promptly.
Secondly, I'd like to discuss a little something I thought about
regarding when PHP will/will not throw an error dealing with primitive
types. Specifically when dealing with user input (which always comes
across as a string to start), if you had something like...
function foo(int $a, int $b) { return $a + $b; }
and called:
foo($_GET['a'], $_GET['b']); // $_GET['a'] === foo, $_GET['b'] === 5
According to Zeev's description of the behavior this would cause a
fatal error, as $_GET['a'] cannot be converted to an integer value.. I
like that, but I think we need to devise a mechanism that allows you
to catch this error at runtime and write application logic around
it... In the simple case above the point would be to be able to catch
the error so that the requesting user could be informed he must enter
two integer values. Off the top of my head the only mechanism that I
can think of would be to throw an exception, which I'm not crazy about
either:
try
{
print foo($_GET['a'], $_GET['b']);
} catch(TypeCheckException $e) {
print Sorry, you need to provide two integer values!;
}
Personally I really like the practical feel and ease of understanding
of using an exception in this case, but the idea of an exception being
thrown from potentially procedural code isn't the best thing to me..
John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
