Re: [PHP-DEV] RE: Optional scalar type hinting
It really doesn't fit in very well with PHP's loosely typed nature which is one of the main reasons it has been so easy to use. I think this is one of the cornerstones that two sides disagree the most on. People are afraid that PHP would turn into a strong-typed language by allowing type hinting for scalar values. I do not think this would be the case. You would still have all the freedom that you have no with PHP, since PHP's type juggling is still in effect. The only thing that would change is that the validation of the data that is passed into functions would be somewhat automated, but since the validation occurs with or without type hinting the result is still the same. If data is incorrent, an error occurs whether it is an exception, a false return type, or a triggered error. The behaviour of the program does not change with type hinting. Even this thread shows that there's no alignment between people on what it should actually do. This is true, but contributed to it is that so far we have spent more time and energy on the silly debate whether or not type hinting is a useful feature. There is enough technical proof to suggest that it is in fact a useful feature. What I would like to see is actual discussion on how it should behave and see if a concensus can be derived. Saying that it won't confuse newbies is also wrong. PHP is so popular because it's so easy for people to pick up. Part of this also includes ability to look at other people's code, understand it, copy-on-write (e.g. a Wordpress plug-in). This is an argument that I honestly do not understand. Type hinting is already here. It exists in PHP. How can the concept be abandoned on the bases that it would confuse new users, if the concept has already been approved and implemented? Tomi Kaistila PHP Developer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 3 Jan 2008, Stanislav Malyshev wrote: I don't get it. We already have type hinting, just not for scalars. The Type hinting for scalars is different because it disables one of the features of PHP language - conversion of scalar types into each other. It doesn't disable this. It's still there if you want it. If you want slightly more control, you can have it too. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 3 Jan 2008, Sam Barrow wrote: It doesn't disable type conversion unless you specifically tell it to. Plus the fact that if it issues an E_WARNING, your application will not necessarily stop execution. Stop right here for a moment. Type hints currently throw an E_RECOVERABLE_ERROR, for obvious reasons. That means, that scalar type hints should do so as well - *without* auto conversion. We should not make this inconsistent or we really fucked it up. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 3 Jan 2008, Sam Barrow wrote: On Thu, 2008-01-03 at 22:37 +0100, Markus Fischer wrote: Of course, Jochem, you're right. Exceptions would be nice. WrongArgumentException, InvalidWhateverException, ... That would be very nice. The full blown suite of exception error handlers could be a future project, depending on code contributors and community support. As for my patch, I think we can all agree on E_WARNING. Definitely not. Type hints now throw E_RECOVERABLE_ERROR, and that should be the same for any other typehinting system that we add. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 2008-01-03 at 15:58 -0600, Brian Moon wrote: I don't get it. We already have type hinting, just not for scalars. The discussion seems to be about whether or not we should have it all. But, the truth is, we have it. We half way have it. I fought for it to be all or nothing back then and I still think it is half done that we don't have scalar type hinting but we have array/object/class type hinting. Talk about inconsistency. So, can we switch the mundane conversation from should we have type hinting to why don't we have scalar type hinting if we have non-scalar type hinting? That is the real conversation. Type hinting is here. It is not going anywhere. Let's finish the job. Yes. Atleast add a scalar type hint to differentiate from arrays and objects. A scalar type hint complies with PHP's way of not differentiating too much between strings, booleans, integers, and floats. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Fri, 2008-01-04 at 10:06 +0200, Tomi Kaistila wrote: It really doesn't fit in very well with PHP's loosely typed nature which is one of the main reasons it has been so easy to use. I think this is one of the cornerstones that two sides disagree the most on. People are afraid that PHP would turn into a strong-typed language by allowing type hinting for scalar values. I do not think this would be the case. You would still have all the freedom that you have no with PHP, since PHP's type juggling is still in effect. The only thing that would change is that the validation of the data that is passed into functions would be somewhat automated, but since the validation occurs with or without type hinting the result is still the same. If data is incorrent, an error occurs whether it is an exception, a false return type, or a triggered error. The behaviour of the program does not change with type hinting. Exactly. This is not strict typing. It's type hinting (key word, hinting). Even this thread shows that there's no alignment between people on what it should actually do. This is true, but contributed to it is that so far we have spent more time and energy on the silly debate whether or not type hinting is a useful feature. There is enough technical proof to suggest that it is in fact a useful feature. What I would like to see is actual discussion on how it should behave and see if a concensus can be derived. Saying that it won't confuse newbies is also wrong. PHP is so popular because it's so easy for people to pick up. Part of this also includes ability to look at other people's code, understand it, copy-on-write (e.g. a Wordpress plug-in). This is an argument that I honestly do not understand. Type hinting is already here. It exists in PHP. How can the concept be abandoned on the bases that it would confuse new users, if the concept has already been approved and implemented? Exactly, array and class type hints are actually more confusing than scalar type hints. What's more confusing to a beginner, having to pass an instance of a certain object to a function, or having to pass a number or string? Tomi Kaistila PHP Developer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: Optional scalar type hinting
See below:
-Original Message-
From: Sam Barrow [mailto:[EMAIL PROTECTED]
Sent: Friday, January 04, 2008 5:47 AM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: RE: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 2008-01-03 at 21:34 -0800, Andi Gutmans wrote:
We've discussed scalar type hinting many times in the past and
decided
against it.
It really doesn't fit in very well with PHP's loosely typed nature
which
is one of the main reasons it has been so easy to use. The only
reason
why it works with classes and arrays is because those are
unambiguous
constructs.
It doesn't fit. This is not a technical argument, this is your opinion
on the way PHP should be. That's the problem here.
Are you saying that languages are designed only based on technicalities?
So why are languages so different? Each language has a spirit and an
emphasis and this is definitely something to think about. It also
relates to what the applicable market and users are.
-snip-
So why don't we first see if people can agree on what this does:
I think all the following ones should work:
function iwantint(int $n) {
iwantint(1); // 1 + 1 works great.
function iwantstring(string $str) {}
iwantstring($toStringObject); // Works in strcmp()
function iwantfloat(float $f) {}
iwantfloat(2);
function iwantbool(bool $b) {}
iwantbool(1);
function iwantnull(null $n) {}
iwantnull(null);//Does this exist?
And for consistency of the language we would be using PHP's type
juggling system to see if there's a match or not and you'd get whatever
results you get today.
Btw I think there's absolutely no argument that the error should be
exactly the same as with array/class hints. No way are we going to have
two different errors for the same kind of functionality. That's
ludicrous.
More below:...
Saying that it won't confuse newbies is also wrong. PHP is so
popular
because it's so easy for people to pick up. Part of this also
includes
ability to look at other people's code, understand it, copy-on-write
(e.g. a Wordpress plug-in). The more features in PHP the harder
it'll
be
for developers to deal with. Yes, we bit the bullet for namespaces
because there were strong reasons in favor of it, we as a community
had
it on our wishlist for a long time and a lot of work went into it.
And
even when we did it we had to find a way to make it work for PHP. In
this case, with the lose typing of PHP creating a consistent model
which
will be apparent to people without many questions is a big issue.
I've said this numerous times too. How hard is it to understand? If
someone can't understand this simple concept they are sure as hell not
going to understand object oriented or anything.
There are actually a lot of PHP developers who don't do OO oriented.
This is why we left it as a choice to developers (it's been around btw
since 1997 at least the basic OO functionality).
Anyway what's confusing here are the semantics not the feature itself.
For example, I expect something different than you do.
Plus the fact that this is actually easier to understand than
array/object type hints.
I don't think so because there's no potential type juggling in those
(which is why we did it) but it's a pointless argument because it
doesn't add much value to the discussion.
Also, for those who say that when this feature is not used it
doesn't
have a performance impact that is also a problematic statement. If
it
exists people will use it. Most people using PHP don't understand
(and
shouldn't have to understand) how the language is implemented. It
may
very well be that even if we could agree on the semantics we'll see
all
sorts of developers decorate their code with type hints (because
they
think it'll help readability) who may down the road find themselves
in a
surprise when it comes to performance.
Well that's their decision. I could use functions and not use a single
class in my applications, and they would be faster. I sacrifice a
little
performance in order to make my code better.
Last, just because something can be implemented and a patch exists
doesn't mean it should be in PHP. There are lots of things I can
implement for PHP which shouldn't be in PHP. Also don't under
estimate
what happens when you get bloatware and over time how much harder it
becomes to maintain and also how it does eventually end up slowing
things down (over time there are more branches, more code a.k.a more
cache misses, etc...)
You are right here. But define bloatware. Type hinting is already in
PHP. All I want to do is add a couple of types to this already
implemented feature. My patch is pretty small.
Small small but the way it is currently implemented I both don't agree
with (semantics) and I think it can also be implemented better (for
starters I'd use a switch() statement in the runtime piece. I am not too
worried about zend_compile.c).
P.S
Re: [PHP-DEV] RE: Optional scalar type hinting
I've stated my opinion on this, I'm going for standard hinting. Int means int, not 1 or one or 1one. Bool means boolean true or false, I don't see any difference in substance between 1 and 1. not true, 1, 0, 0, etc. Same for boolean - I don't see any substantial difference between (int)0, (float)0 and (boolean)false and see no reason ever to make a function that distinguishes between those. Now, statically-typed compiled languages do it for the very good reason - it is very hard to implement such versatile API manually. It is infeasible to make all C function declared as foo(int i) to take char* instead and use atoi() or whatever it needs to be - and do it for each and every function. That's exactly why scripting languages with loose typing were created - to allow programmers to get rid of these technicalities and work with substance of the values, not with bit representation of them. Now you come back and say - no, my function would accept (boolean)0 but would pretend it can not handle (int)0 because the bits in a type field of the variable are wrong. What could be the practical purpose of such dumbing-down? Getting all the stress of the programming in statically typed language without compile-time checking and safety as a compensation for the stress? Doesn't look as a good deal for me. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: Optional scalar type hinting
On Fri, 2008-01-04 at 10:08 -0800, Andi Gutmans wrote:
See below:
-Original Message-
From: Sam Barrow [mailto:[EMAIL PROTECTED]
Sent: Friday, January 04, 2008 5:47 AM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: RE: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 2008-01-03 at 21:34 -0800, Andi Gutmans wrote:
We've discussed scalar type hinting many times in the past and
decided
against it.
It really doesn't fit in very well with PHP's loosely typed nature
which
is one of the main reasons it has been so easy to use. The only
reason
why it works with classes and arrays is because those are
unambiguous
constructs.
It doesn't fit. This is not a technical argument, this is your opinion
on the way PHP should be. That's the problem here.
Are you saying that languages are designed only based on technicalities?
So why are languages so different? Each language has a spirit and an
emphasis and this is definitely something to think about. It also
relates to what the applicable market and users are.
True. I'm saying that this is being taken too far in this case. PHP with
type hinting is still PHP, I am not asking to redesign the entire
structure of the language.
-snip-
So why don't we first see if people can agree on what this does:
I think all the following ones should work:
function iwantint(int $n) {
iwantint(1);// 1 + 1 works great.
function iwantstring(string $str) {}
iwantstring($toStringObject); // Works in strcmp()
function iwantfloat(float $f) {}
iwantfloat(2);
function iwantbool(bool $b) {}
iwantbool(1);
function iwantnull(null $n) {}
iwantnull(null); //Does this exist?
Null hint does not exist, as null is only one value and it would be
pointless.
I've stated my opinion on this, I'm going for standard hinting. Int
means int, not 1 or one or 1one. Bool means boolean true or false,
not true, 1, 0, 0, etc.
And for consistency of the language we would be using PHP's type
juggling system to see if there's a match or not and you'd get whatever
results you get today.
Btw I think there's absolutely no argument that the error should be
exactly the same as with array/class hints. No way are we going to have
two different errors for the same kind of functionality. That's
ludicrous.
Errors should all be the same for any type hint.
More below:...
Saying that it won't confuse newbies is also wrong. PHP is so
popular
because it's so easy for people to pick up. Part of this also
includes
ability to look at other people's code, understand it, copy-on-write
(e.g. a Wordpress plug-in). The more features in PHP the harder
it'll
be
for developers to deal with. Yes, we bit the bullet for namespaces
because there were strong reasons in favor of it, we as a community
had
it on our wishlist for a long time and a lot of work went into it.
And
even when we did it we had to find a way to make it work for PHP. In
this case, with the lose typing of PHP creating a consistent model
which
will be apparent to people without many questions is a big issue.
I've said this numerous times too. How hard is it to understand? If
someone can't understand this simple concept they are sure as hell not
going to understand object oriented or anything.
There are actually a lot of PHP developers who don't do OO oriented.
This is why we left it as a choice to developers (it's been around btw
since 1997 at least the basic OO functionality).
OK. And they're not using OO right? So tell them not to use type hinting
either!
Anyway what's confusing here are the semantics not the feature itself.
For example, I expect something different than you do.
Plus the fact that this is actually easier to understand than
array/object type hints.
I don't think so because there's no potential type juggling in those
(which is why we did it) but it's a pointless argument because it
doesn't add much value to the discussion.
You have a point, but it is still a very simple concept.
Also, for those who say that when this feature is not used it
doesn't
have a performance impact that is also a problematic statement. If
it
exists people will use it. Most people using PHP don't understand
(and
shouldn't have to understand) how the language is implemented. It
may
very well be that even if we could agree on the semantics we'll see
all
sorts of developers decorate their code with type hints (because
they
think it'll help readability) who may down the road find themselves
in a
surprise when it comes to performance.
Well that's their decision. I could use functions and not use a single
class in my applications, and they would be faster. I sacrifice a
little
performance in order to make my code better.
Last, just because something can be implemented and a patch exists
doesn't mean it should be in PHP
Re: [PHP-DEV] RE: Optional scalar type hinting
Definitely not. Type hints now throw E_RECOVERABLE_ERROR, and that should be the same for any other typehinting system that we add. Then we don't add any, because without static type control it's just a ticking timebomb waiting to blow up your production code (and having application display An internal error happened, please contact developers is blowing up no less than having blank screen). -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Optional scalar type hinting
Hello everyone I figured I would bring my opinion in to support of Sam's request for a more complete type hinting feature. Namely I am interested in the support for hinting scalar types on function and method arguments and I am sure it is safe for me to say that I speak for a lot of people. Most people that I know find the current type hinting, while useful, ridiculous because it looks like the job was left unfinished for whatever abstract reason. In my opinion type hinting should definitely be allowed for scalar values. As for return types, I am not so sure. So far I have found no use for such a feature in my own code, so I won't comment on it. If it is added, I welcome it for those who find it useful but if it is not added I will not loose sleep over it. I was thinking at something along the lines of objects also for instance: $i = new Integer(33); After my own experiments with the subject I concur that while it can be made to work, it is not only a bad idea (for the reasons mentioned earlier) it is also redundant and just unnecessary. There is a lot better way to accomplish the same and that by allowing scalar values to be hinted. It is simpler, cleaner, and easier to implement. What if type hinting just generated an E_NOTICE. Nothing more for the time being. Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since if I write a piece of code that hints that the argument for a-whatever method needs to be an integer it seems useless if the user of my library can avoid the issue just by supressing lesser errors and those who do not need to write extensive error handling code to respond to this sort of error (if they indeed deem it necessary to do so). While hinting is, and should remain, optional, when it is used it should be enforced. After all the user of my library has the option to dump it and go for another library that does not force types. That is the beauty of having options. Tomi Kaistila PHP Developer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?
And about function return type hinting, I don't think it would be as
useful as parameter type hinting, but it would be useful. Mostly for
stuff like declaring an abstract function in a parent class that must
return a certain type.
class a {
abstract public function getNumber() returns int ;
}
class b extends a {
public function getNumber() {
return rand() * 3463 ;
}
}
class c extends a {
public function getNumber() {
return 'I\'m going to mess everything up by returning a
string.' ; //
Would cause error with type hinting.
}
}
On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:
Hello everyone
I figured I would bring my opinion in to support of Sam's request for a more
complete type hinting feature. Namely I am interested in the support for
hinting scalar types on function and method arguments and I am sure it is
safe for me to say that I speak for a lot of people. Most people that I know
find the current type hinting, while useful, ridiculous because it looks like
the job was left unfinished for whatever abstract reason.
In my opinion type hinting should definitely be allowed for scalar values. As
for return types, I am not so sure. So far I have found no use for such a
feature in my own code, so I won't comment on it. If it is added, I welcome
it for those who find it useful but if it is not added I will not loose sleep
over it.
I was thinking at something along the lines of objects also for instance:
$i = new Integer(33);
After my own experiments with the subject I concur that while it can be made
to work, it is not only a bad idea (for the reasons mentioned earlier) it is
also redundant and just unnecessary. There is a lot better way to accomplish
the same and that by allowing scalar values to be hinted. It is simpler,
cleaner, and easier to implement.
What if type hinting just generated an E_NOTICE. Nothing more for the
time being.
Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since if I
write a piece of code that hints that the argument for a-whatever method
needs to be an integer it seems useless if the user of my library can avoid
the issue just by supressing lesser errors and those who do not need to write
extensive error handling code to respond to this sort of error (if they
indeed deem it necessary to do so).
While hinting is, and should remain, optional, when it is used it should be
enforced. After all the user of my library has the option to dump it and go
for another library that does not force types. That is the beauty of having
options.
Tomi Kaistila
PHP Developer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?
And about function return type hinting, I don't think it would be as
useful as parameter type hinting, but it would be useful. Mostly for
stuff like declaring an abstract function in a parent class that must
return a certain type.
class a {
abstract public function getNumber() returns int ;
}
class b extends a {
public function getNumber() {
return rand() * 3463 ;
}
}
class c extends a {
public function getNumber() {
return 'I\'m going to mess everything up by returning a
string.' ; //
Would cause error with type hinting.
}
}
On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:
Hello everyone
I figured I would bring my opinion in to support of Sam's request for
a more
complete type hinting feature. Namely I am interested in the support
for
hinting scalar types on function and method arguments and I am sure it
is
safe for me to say that I speak for a lot of people. Most people that
I know
find the current type hinting, while useful, ridiculous because it
looks like
the job was left unfinished for whatever abstract reason.
In my opinion type hinting should definitely be allowed for scalar
values. As
for return types, I am not so sure. So far I have found no use for
such a
feature in my own code, so I won't comment on it. If it is added, I
welcome
it for those who find it useful but if it is not added I will not
loose sleep
over it.
I was thinking at something along the lines of objects also for
instance:
$i = new Integer(33);
After my own experiments with the subject I concur that while it can
be made
to work, it is not only a bad idea (for the reasons mentioned earlier)
it is
also redundant and just unnecessary. There is a lot better way to
accomplish
the same and that by allowing scalar values to be hinted. It is
simpler,
cleaner, and easier to implement.
What if type hinting just generated an E_NOTICE. Nothing more for
the
time being.
Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat
since if I
write a piece of code that hints that the argument for a-whatever
method
needs to be an integer it seems useless if the user of my library can
avoid
the issue just by supressing lesser errors and those who do not need
to write
extensive error handling code to respond to this sort of error (if
they
indeed deem it necessary to do so).
While hinting is, and should remain, optional, when it is used it
should be
enforced. After all the user of my library has the option to dump it
and go
for another library that does not force types. That is the beauty of
having
options.
Tomi Kaistila
PHP Developer
On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:
Hello everyone
I figured I would bring my opinion in to support of Sam's request for a more
complete type hinting feature. Namely I am interested in the support for
hinting scalar types on function and method arguments and I am sure it is
safe for me to say that I speak for a lot of people. Most people that I know
find the current type hinting, while useful, ridiculous because it looks like
the job was left unfinished for whatever abstract reason.
In my opinion type hinting should definitely be allowed for scalar values. As
for return types, I am not so sure. So far I have found no use for such a
feature in my own code, so I won't comment on it. If it is added, I welcome
it for those who find it useful but if it is not added I will not loose sleep
over it.
I was thinking at something along the lines of objects also for instance:
$i = new Integer(33);
After my own experiments with the subject I concur that while it can be made
to work, it is not only a bad idea (for the reasons mentioned earlier) it is
also redundant and just unnecessary. There is a lot better way to accomplish
the same and that by allowing scalar values to be hinted. It is simpler,
cleaner, and easier to implement.
What if type hinting just generated an E_NOTICE. Nothing more for the
time being.
Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since if I
write a piece of code that hints that the argument for a-whatever method
needs to be an integer it seems useless if the user of my library can avoid
the issue just by supressing lesser errors and those who do not need to write
extensive error handling code to respond to this sort of error (if they
indeed deem it necessary to do so).
While hinting is, and should remain, optional, when it is used it should be
enforced. After all the user of my library has the option to dump it and go
for another library that does not force types. That is the beauty of having
options.
Tomi Kaistila
PHP Developer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, Jan 03, 2008 at 12:21:21PM -0500, Sam Barrow wrote: I think E_WARNING would be appropriate. That's what happens when you omit an argument to a function right? The other thing to note about type hinting is that it could result in faster code. The value is checked and if needed converted (eg string - integer) when the function is called; it then need not be converted again when it is used in the function. This will presumably be a win if the value is used more than once. -- Alain Williams Linux 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 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] RE: Optional scalar type hinting
Yes it seems PHP will omit E_WARNING if you omit an argument.
(Had to actually check.)
Not a bad choice for an error and probably also easier to manage when you are
dealing with complicated error handling in large applications.
I would suggest E_WARNING or E_FATAL, but not E_NOTICE or E_STRICT, for the
simple fact that they are ignore by a major portion of PHP developers and to
use them would prompt a high risk of people writing bad code.
Also, now that you mentioned abstract classes, type hinting might also be
useful with interfaces.
Tomi Kaistila
PHP Developer
On Thursday 03 January 2008 19:21:21 you wrote:
I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?
And about function return type hinting, I don't think it would be as
useful as parameter type hinting, but it would be useful. Mostly for
stuff like declaring an abstract function in a parent class that must
return a certain type.
class a {
abstract public function getNumber() returns int ;
}
class b extends a {
public function getNumber() {
return rand() * 3463 ;
}
}
class c extends a {
public function getNumber() {
return 'I\'m going to mess everything up by returning a
string.' ; //
Would cause error with type hinting.
}
}
On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:
Hello everyone
I figured I would bring my opinion in to support of Sam's request for a
more complete type hinting feature. Namely I am interested in the support
for hinting scalar types on function and method arguments and I am sure
it is safe for me to say that I speak for a lot of people. Most people
that I know find the current type hinting, while useful, ridiculous
because it looks like the job was left unfinished for whatever abstract
reason.
In my opinion type hinting should definitely be allowed for scalar
values. As for return types, I am not so sure. So far I have found no use
for such a feature in my own code, so I won't comment on it. If it is
added, I welcome it for those who find it useful but if it is not added I
will not loose sleep over it.
I was thinking at something along the lines of objects also for
instance: $i = new Integer(33);
After my own experiments with the subject I concur that while it can be
made to work, it is not only a bad idea (for the reasons mentioned
earlier) it is also redundant and just unnecessary. There is a lot better
way to accomplish the same and that by allowing scalar values to be
hinted. It is simpler, cleaner, and easier to implement.
What if type hinting just generated an E_NOTICE. Nothing more for the
time being.
Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since
if I write a piece of code that hints that the argument for a-whatever
method needs to be an integer it seems useless if the user of my library
can avoid the issue just by supressing lesser errors and those who do not
need to write extensive error handling code to respond to this sort of
error (if they indeed deem it necessary to do so).
While hinting is, and should remain, optional, when it is used it should
be enforced. After all the user of my library has the option to dump it
and go for another library that does not force types. That is the beauty
of having options.
Tomi Kaistila
PHP Developer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Alain Williams wrote: On Thu, Jan 03, 2008 at 12:21:21PM -0500, Sam Barrow wrote: I think E_WARNING would be appropriate. That's what happens when you omit an argument to a function right? The other thing to note about type hinting is that it could result in faster code. The value is checked and if needed converted (eg string - integer) when the function is called; it then need not be converted again when it is used in the function. This will presumably be a win if the value is used more than once. I don't think that automagic conversion of types is a good idea. When the type hint says I want an integer, then only integer should be accepted; no casting should be done. It may give predictable results according to the documentation but not always very intuitive. I sense a possible small trap, and after all type hints should help developers get code right and spot problems easier without less work. PHP supports explicit casting and that should be used for that. Because if this results in a problem alter in the code you know who to blame: yourself, and not the automagic behavior of PHP. my 2c, - - Markus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfStA1nS0RcInK9ARAu/dAKDNOMC7M1X8CyrjyCrpzt0/oiLsCgCg2YSY YAUYre0HTc3dLxsbHTu7+Ik= =KXMz -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
am I the only one to consider E_FATAL (as generated for class typehints) makes
type hinting useless - given that there is no compile stage at which to catch
typehint related mistakes. which means there is no way to trap the issue and
offer some useful/user-friendly feedback to the user (in practice it usually
means the white page of death for a site visitor)
E_WARNING also is not much better given that one would assume the
function/method
that was passed incorrect variables (according to type) wouldn't run.
would an exception not be the most suitable thing to generate on a typehint
error?
to me anything else makes typehinting in production environments pretty much
unusable
unless one write code like so:
function foo(Foo $f) { /* do foo stuff */ }
$f = getFoo();
if ($f instanceof Foo) {
foo($f);
}
now the issue with such code is not that it is alot more verbose than might
strictly be needed but that the instanceof statement makes the typehint rather
superfluous.
Tomi Kaistila schreef:
Yes it seems PHP will omit E_WARNING if you omit an argument.
(Had to actually check.)
Not a bad choice for an error and probably also easier to manage when you are
dealing with complicated error handling in large applications.
I would suggest E_WARNING or E_FATAL, but not E_NOTICE or E_STRICT, for the
simple fact that they are ignore by a major portion of PHP developers and to
use them would prompt a high risk of people writing bad code.
Also, now that you mentioned abstract classes, type hinting might also be
useful with interfaces.
Tomi Kaistila
PHP Developer
On Thursday 03 January 2008 19:21:21 you wrote:
I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?
And about function return type hinting, I don't think it would be as
useful as parameter type hinting, but it would be useful. Mostly for
stuff like declaring an abstract function in a parent class that must
return a certain type.
class a {
abstract public function getNumber() returns int ;
}
class b extends a {
public function getNumber() {
return rand() * 3463 ;
}
}
class c extends a {
public function getNumber() {
return 'I\'m going to mess everything up by returning a
string.' ; //
Would cause error with type hinting.
}
}
On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:
Hello everyone
I figured I would bring my opinion in to support of Sam's request for a
more complete type hinting feature. Namely I am interested in the support
for hinting scalar types on function and method arguments and I am sure
it is safe for me to say that I speak for a lot of people. Most people
that I know find the current type hinting, while useful, ridiculous
because it looks like the job was left unfinished for whatever abstract
reason.
In my opinion type hinting should definitely be allowed for scalar
values. As for return types, I am not so sure. So far I have found no use
for such a feature in my own code, so I won't comment on it. If it is
added, I welcome it for those who find it useful but if it is not added I
will not loose sleep over it.
I was thinking at something along the lines of objects also for
instance: $i = new Integer(33);
After my own experiments with the subject I concur that while it can be
made to work, it is not only a bad idea (for the reasons mentioned
earlier) it is also redundant and just unnecessary. There is a lot better
way to accomplish the same and that by allowing scalar values to be
hinted. It is simpler, cleaner, and easier to implement.
What if type hinting just generated an E_NOTICE. Nothing more for the
time being.
Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since
if I write a piece of code that hints that the argument for a-whatever
method needs to be an integer it seems useless if the user of my library
can avoid the issue just by supressing lesser errors and those who do not
need to write extensive error handling code to respond to this sort of
error (if they indeed deem it necessary to do so).
While hinting is, and should remain, optional, when it is used it should
be enforced. After all the user of my library has the option to dump it
and go for another library that does not force types. That is the beauty
of having options.
Tomi Kaistila
PHP Developer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
I think we should stick with E_WARNING for now. If you want to use
exceptions you can throw one in a custom error handler. I can change
about 4 lines of code in my patch to have it emit an E_WARNING easily.
On Thu, 2008-01-03 at 19:49 +0100, Jochem Maas wrote:
am I the only one to consider E_FATAL (as generated for class typehints) makes
type hinting useless - given that there is no compile stage at which to catch
typehint related mistakes. which means there is no way to trap the issue and
offer some useful/user-friendly feedback to the user (in practice it usually
means the white page of death for a site visitor)
E_WARNING also is not much better given that one would assume the
function/method
that was passed incorrect variables (according to type) wouldn't run.
would an exception not be the most suitable thing to generate on a typehint
error?
to me anything else makes typehinting in production environments pretty much
unusable
unless one write code like so:
function foo(Foo $f) { /* do foo stuff */ }
$f = getFoo();
if ($f instanceof Foo) {
foo($f);
}
now the issue with such code is not that it is alot more verbose than might
strictly be needed but that the instanceof statement makes the typehint rather
superfluous.
Tomi Kaistila schreef:
Yes it seems PHP will omit E_WARNING if you omit an argument.
(Had to actually check.)
Not a bad choice for an error and probably also easier to manage when you
are
dealing with complicated error handling in large applications.
I would suggest E_WARNING or E_FATAL, but not E_NOTICE or E_STRICT, for the
simple fact that they are ignore by a major portion of PHP developers and
to
use them would prompt a high risk of people writing bad code.
Also, now that you mentioned abstract classes, type hinting might also be
useful with interfaces.
Tomi Kaistila
PHP Developer
On Thursday 03 January 2008 19:21:21 you wrote:
I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?
And about function return type hinting, I don't think it would be as
useful as parameter type hinting, but it would be useful. Mostly for
stuff like declaring an abstract function in a parent class that must
return a certain type.
class a {
abstract public function getNumber() returns int ;
}
class b extends a {
public function getNumber() {
return rand() * 3463 ;
}
}
class c extends a {
public function getNumber() {
return 'I\'m going to mess everything up by returning a
string.' ; //
Would cause error with type hinting.
}
}
On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:
Hello everyone
I figured I would bring my opinion in to support of Sam's request for a
more complete type hinting feature. Namely I am interested in the support
for hinting scalar types on function and method arguments and I am sure
it is safe for me to say that I speak for a lot of people. Most people
that I know find the current type hinting, while useful, ridiculous
because it looks like the job was left unfinished for whatever abstract
reason.
In my opinion type hinting should definitely be allowed for scalar
values. As for return types, I am not so sure. So far I have found no use
for such a feature in my own code, so I won't comment on it. If it is
added, I welcome it for those who find it useful but if it is not added I
will not loose sleep over it.
I was thinking at something along the lines of objects also for
instance: $i = new Integer(33);
After my own experiments with the subject I concur that while it can be
made to work, it is not only a bad idea (for the reasons mentioned
earlier) it is also redundant and just unnecessary. There is a lot better
way to accomplish the same and that by allowing scalar values to be
hinted. It is simpler, cleaner, and easier to implement.
What if type hinting just generated an E_NOTICE. Nothing more for the
time being.
Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since
if I write a piece of code that hints that the argument for a-whatever
method needs to be an integer it seems useless if the user of my library
can avoid the issue just by supressing lesser errors and those who do not
need to write extensive error handling code to respond to this sort of
error (if they indeed deem it necessary to do so).
While hinting is, and should remain, optional, when it is used it should
be enforced. After all the user of my library has the option to dump it
and go for another library that does not force types. That is the beauty
of having options.
Tomi Kaistila
PHP Developer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
When the type hint says I want an integer, then only integer should be accepted; no casting should be done. It may give predictable results Why people that want Java just don't use Java I wonder? PHP never was a strict static typed language. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
But with the current situation it feels very awkward. We get class and array type hints but not the other scalar types?! :-/ Arrays and objects aren't scalar types, so other scalar types are in fact all on them. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, you're right. However to me it's an unimportant factor but maybe not for the ones who don't like to see type hints (but I don't know what there arguments are). thanks, - - Markus Stanislav Malyshev wrote: But with the current situation it feels very awkward. We get class and array type hints but not the other scalar types?! :-/ Arrays and objects aren't scalar types, so other scalar types are in fact all on them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfTWe1nS0RcInK9ARAvlJAKCvC5rcQ1je1wbnht3GCacQ7E5HoQCgq/Ix H9GKXUubMQupLwhx1icukFM= =jQSH -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 3 Jan 2008, Stanislav Malyshev wrote: When the type hint says I want an integer, then only integer should be accepted; no casting should be done. It may give predictable results Why people that want Java just don't use Java I wonder? PHP never was a strict static typed language. Broken record perhaps? I am getting a bit tired of this just use Java argument, it's perhaps even a bit arrogant. From what I read there is plenty of people that want type hints for static types - there's a few patches out there, it doesn't slow down the general case. So why should we *not* add it? (And yes, I changed my mind) regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Stanislav Malyshev wrote: When the type hint says I want an integer, then only integer should be accepted; no casting should be done. It may give predictable results Why people that want Java just don't use Java I wonder? PHP never was a strict static typed language. I can't answer you that one :) I want PHP and not Java. Yet I would like to have type hinting. Don't see a conflict here. But with the current situation it feels very awkward. We get class and array type hints but not the other scalar types?! :-/ - - Markus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfTDj1nS0RcInK9ARAqL3AJsFeFxW/m+xonir+ukKEtOHU/m/WQCfetSx wvy6jLFuSclijBClsADGG+8= =8Lwh -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
Thank you. As long as a feature is useful, why not add it? Just because some people don't find it useful, this is not at all a reason to completely discard the idea, especially when the only argument is well PHP doesn't need that so just use another language. On Thu, 2008-01-03 at 20:23 +0100, Derick Rethans wrote: On Thu, 3 Jan 2008, Stanislav Malyshev wrote: When the type hint says I want an integer, then only integer should be accepted; no casting should be done. It may give predictable results Why people that want Java just don't use Java I wonder? PHP never was a strict static typed language. Broken record perhaps? I am getting a bit tired of this just use Java argument, it's perhaps even a bit arrogant. From what I read there is plenty of people that want type hints for static types - there's a few patches out there, it doesn't slow down the general case. So why should we *not* add it? (And yes, I changed my mind) regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
Just so anyone who wants it has it, I have attached the last version of
my patch.
Note that it still issues a fatal error but this can be changed very
easily, would take me about 2 minutes.
Full specs:
Type hinting patch allows for 8 new type hints, in addition to array and
class type hinting.
- Integers (specified by int, integer, or long)
- Floats (specified by float, double, or real)
- Numbers (matches integers and floats, specified by num or number)
- Strings (specified by string)
- Booleans (specified by bool or boolean)
- Scalars (matches strings, booleans, and numbers; specified by
scalar)
- Resources (specified by resource)
- Objects (matches any object, specified by object)
The patch specifies a constant, PATCH_SCALAR_TYPE_HINTING, just there to
indicate that the patch is installed.
On Thu, 2008-01-03 at 20:23 +0100, Derick Rethans wrote:
On Thu, 3 Jan 2008, Stanislav Malyshev wrote:
When the type hint says I want an integer, then only integer should be
accepted; no casting should be done. It may give predictable results
Why people that want Java just don't use Java I wonder? PHP never was a
strict
static typed language.
Broken record perhaps? I am getting a bit tired of this just use Java
argument, it's perhaps even a bit arrogant. From what I read there is
plenty of people that want type hints for static types - there's a few
patches out there, it doesn't slow down the general case. So why should
we *not* add it? (And yes, I changed my mind)
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
Index: Zend/zend_API.h
===
RCS file: /repository/ZendEngine2/zend_API.h,v
retrieving revision 1.207.2.8.2.8.2.5
diff -u -r1.207.2.8.2.8.2.5 zend_API.h
--- Zend/zend_API.h 2 Nov 2007 19:40:37 - 1.207.2.8.2.8.2.5
+++ Zend/zend_API.h 21 Dec 2007 20:56:40 -
@@ -69,7 +69,7 @@
#define ZEND_ARG_ARRAY_INFO(pass_by_ref, name, allow_null) { #name, sizeof(#name)-1, NULL, 0, 1, allow_null, pass_by_ref, 0, 0 },
#define ZEND_BEGIN_ARG_INFO_EX(name, pass_rest_by_reference, return_reference, required_num_args) \
const zend_arg_info name[] = { \
- { NULL, 0, NULL, 0, 0, 0, pass_rest_by_reference, return_reference, required_num_args },
+ { NULL, 0, NULL, 0, 0, 0, pass_rest_by_reference, return_reference, required_num_args, 0, 0, 0 },
#define ZEND_BEGIN_ARG_INFO(name, pass_rest_by_reference) \
ZEND_BEGIN_ARG_INFO_EX(name, pass_rest_by_reference, ZEND_RETURN_VALUE, -1)
#define ZEND_END_ARG_INFO() };
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.31
diff -u -r1.647.2.27.2.41.2.31 zend_compile.c
--- Zend/zend_compile.c 13 Dec 2007 10:02:03 - 1.647.2.27.2.41.2.31
+++ Zend/zend_compile.c 21 Dec 2007 20:56:41 -
@@ -1341,26 +1341,54 @@
cur_arg_info-pass_by_reference = pass_by_reference;
cur_arg_info-class_name = NULL;
cur_arg_info-class_name_len = 0;
+ cur_arg_info-scalar_type_hint = 0;
+ cur_arg_info-number_type_hint = 0;
+ cur_arg_info-type_hint = 0;
if (class_type-op_type != IS_UNUSED) {
- cur_arg_info-allow_null = 0;
if (class_type-u.constant.type == IS_STRING) {
- if (ZEND_FETCH_CLASS_DEFAULT == zend_get_class_fetch_type(Z_STRVAL(class_type-u.constant), Z_STRLEN(class_type-u.constant))) {
-zend_resolve_class_name(class_type, opline-extended_value, 1 TSRMLS_CC);
- }
- cur_arg_info-class_name = class_type-u.constant.value.str.val;
- cur_arg_info-class_name_len = class_type-u.constant.value.str.len;
- if (op == ZEND_RECV_INIT) {
-if (Z_TYPE(initialization-u.constant) == IS_NULL || (Z_TYPE(initialization-u.constant) == IS_CONSTANT !strcasecmp(Z_STRVAL(initialization-u.constant), NULL))) {
- cur_arg_info-allow_null = 1;
-} else {
- zend_error(E_COMPILE_ERROR, Default value for parameters with a class type hint can only be NULL);
+ if (strcasecmp(scalar, class_type-u.constant.value.str.val) == 0) {
+ cur_arg_info-scalar_type_hint = 1;
+ } else if (strcasecmp(num, class_type-u.constant.value.str.val) == 0) {
+ cur_arg_info-number_type_hint = 1;
+ } else if (strcasecmp(number, class_type-u.constant.value.str.val) == 0) {
+ cur_arg_info-number_type_hint = 1;
+ } else if (strcasecmp(int, class_type-u.constant.value.str.val) == 0) {
+ cur_arg_info-type_hint = IS_LONG;
+ } else if (strcasecmp(integer, class_type-u.constant.value.str.val) == 0) {
+ cur_arg_info-type_hint = IS_LONG;
+ } else if (strcasecmp(long, class_type-u.constant.value.str.val) == 0) {
+ cur_arg_info-type_hint = IS_LONG;
+ } else if (strcasecmp(float, class_type-u.constant.value.str.val) == 0) {
+ cur_arg_info-type_hint = IS_DOUBLE;
+ } else if (strcasecmp(double, class_type-u.constant.value.str.val) == 0) {
+
Re: [PHP-DEV] RE: Optional scalar type hinting
Broken record perhaps? I am getting a bit tired of this just use Java argument, it's perhaps even a bit arrogant. From what I read there is plenty of people that want type hints for static types - there's a few patches out there, it doesn't slow down the general case. So why should we *not* add it? (And yes, I changed my mind) Same here. I am getting generally tired of the attitude some politically-correct people seem to have about writing javaish code. What the heck is javaish code anyway? Most features that exist in both PHP and Java can also be found in myriad of other languages and it has so far not stopped the development team from adding a feature when it is clearly useful and (most importantly) desired an uncounted number of people. In fact those who oppose the feature seem only capable of doing so with hair-splitting rhetorics. am I the only one to consider E_FATAL (as generated for class typehints) makes type hinting useless - given that there is no compile stage at which to catch typehint related mistakes In principle you are correct. But E_FATAL errors should not happen in a program that is in production use. If they do, it seems someone was not doing their job properly. I am not convinced throwing an exception is the best course of action. If it was, you might make the argument that all errors should be exceptions, while traditionally it is the other way around and changing that is beyond the scope of this thread. I actually like the current division of labor when it comes to error handling. When PHP detects an error, it should actually be an error. Exceptions are convenient for the code that you as a PHP developer can throw. They are especially a blessing when writing library code. That way exceptions work for the error management, instead of competing with it. I say use E_WARNING at this stage. If there is some large redecorating with PHP's error handling in the future, it can be changed then. Tomi Kaistila PHP Developer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 2008-01-03 at 20:50 +0100, Derick Rethans wrote: With that statement I don't agree though. It needs to be usefull for a more general public, and not introduce a huge performance loss for example. You're right, I didn't mean that like it sounded. But a feature that maintains backwards compatibility and doesn't have a major disadvantage for those who choose not to use it is almost always good. In this case, it will benefit many, and to those who choose not to use it, they will probably never even notice it's there. So why not? Because it somehow goes against the ideology of some PHP users? I'm sorry but I just don't see that as reason enough to throw away something that could be very useful. PHP is quickly moving from an easy to learn unprofessional scripting language into an enterprise-level scalable language. Look at it's newer enhanced XML capabilities, improved OO engine, and all of the third-party integration libraries. Finer-grained control over an application (which type hinting contributes to) is something that fits the newer and better language that PHP is becoming. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 3 Jan 2008, Sam Barrow wrote: Thank you. As long as a feature is useful, why not add it? With that statement I don't agree though. It needs to be usefull for a more general public, and not introduce a huge performance loss for example. Derick PS: Top-posting is considered evil on a mailinglist. -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 2008-01-03 at 22:01 +0200, Tomi Kaistila wrote: Broken record perhaps? I am getting a bit tired of this just use Java argument, it's perhaps even a bit arrogant. From what I read there is plenty of people that want type hints for static types - there's a few patches out there, it doesn't slow down the general case. So why should we *not* add it? (And yes, I changed my mind) Same here. I am getting generally tired of the attitude some politically-correct people seem to have about writing javaish code. What the heck is javaish code anyway? Most features that exist in both PHP and Java can also be found in myriad of other languages and it has so far not stopped the development team from adding a feature when it is clearly useful and (most importantly) desired an uncounted number of people. In fact those who oppose the feature seem only capable of doing so with hair-splitting rhetorics. Thank you, I've been thinking this stuff for a while now, ever since the attitude I got when first introducing my patch. I'm glad some people agree with me. I don't care what my code looks like, and it's not written in some holy PHP bible that PHP's one and only purpose of existence is to not be like Java. If a good feature comes along, it should be evaluated on its pros and cons, not whether or not it reminds us of Java or any other language for that matter. I'm sorry I just have no idea where people come up with this stuff. We are supposed to be thinking technically and logically as we are all obviously computer people, not like some Java-hating cult. The issue seems incredibly simple to me, if there's a good feature and it's worth adding, add it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 2008-01-03 at 13:00 -0700, John Coggeshall wrote: Wouldn't this patch also allow for additional performace optimizations which would help counter losses even in the non-general case? Performance optimizations in what way? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
patches out there, it doesn't slow down the general case. So why should we *not* add it? (And yes, I changed my mind) My opinion is that the language is not a salad of features that somebody somewhere found useful. The language should have some directions and properties that make it easy to understand and handy to work with. Having both strict and non-strict typing in the same language does not seem like a good idea to me. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 2008-01-03 at 12:27 -0800, Stanislav Malyshev wrote: patches out there, it doesn't slow down the general case. So why should we *not* add it? (And yes, I changed my mind) My opinion is that the language is not a salad of features that somebody somewhere found useful. The language should have some directions and properties that make it easy to understand and handy to work with. Having both strict and non-strict typing in the same language does not seem like a good idea to me. In a way this is true, but I look at it this way. Some languages are strictly typed, some are dynamically typed. PHP can have the best of both worlds by having optional strict typing where desired, as well as dynamic typing. I have numerous cases where I will have a type hinted parameter and a non type hinted parameter in the same function. This way we can have maximum flexibility where useful, but also control where needed. Keep in mind, this is not strict typing in its correct definition. Strict typing allows very little room for type conversion. This is optionally hinting the desired type of a function parameter. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
Tomi Kaistila schreef: Broken record perhaps? I am getting a bit tired of this just use Java argument, it's perhaps even a bit arrogant. From what I read there is plenty of people that want type hints for static types - there's a few patches out there, it doesn't slow down the general case. So why should we *not* add it? (And yes, I changed my mind) Same here. I am getting generally tired of the attitude some politically-correct people seem to have about writing javaish code. What the heck is javaish code anyway? Most features that exist in both PHP and Java can also be found in myriad of other languages and it has so far not stopped the development team from adding a feature when it is clearly useful and (most importantly) desired an uncounted number of people. In fact those who oppose the feature seem only capable of doing so with hair-splitting rhetorics. am I the only one to consider E_FATAL (as generated for class typehints) makes type hinting useless - given that there is no compile stage at which to catch typehint related mistakes In principle you are correct. But E_FATAL errors should not happen in a program that is in production use. If they do, it seems someone was not doing their job properly. you are right, they shouldn't - but who can say that every execution permutation has been tested and hammered shut in their code (let alone someone else 3rd party lib or extension)? in practice mistakes do occur - and saying someone has not been doing their job properly is little consilation to the end user, client or manager (who gets a white screen of death) ... there is no reason not to let the application try to gracefully handle a mistake like this ... besides I was under the impression that E_FATAL meant the engine was in an unstable state and was unable to continue execution - I don't see why a typehint failure would cause an unstable engine state (rather the engine is presuming that the code is *going* to create an unstable state if it were to continue ... which is not very helpful in my book). I am not convinced throwing an exception is the best course of action. If it was, you might make the argument that all errors should be exceptions, while traditionally it is the other way around and changing that is beyond the scope of this thread. I actually like the current division of labor when it comes to error handling. When PHP detects an error, it should actually be an error. Exceptions are convenient for the code that you as a PHP developer can throw. They are especially a blessing when writing library code. That way exceptions work for the error management, instead of competing with it. I say use E_WARNING at this stage. If there is some large redecorating with PHP's error handling in the future, it can be changed then. that is a very sane arguement. I'll have to concede :-) Tomi Kaistila PHP Developer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Jan 3, 2008 8:23 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Thu, 3 Jan 2008, Stanislav Malyshev wrote: When the type hint says I want an integer, then only integer should be accepted; no casting should be done. It may give predictable results Why people that want Java just don't use Java I wonder? PHP never was a strict static typed language. Broken record perhaps? I am getting a bit tired of this just use Java argument, it's perhaps even a bit arrogant. It is arrogant. For what I see the strictness is making its way in php simply like OO made it. First we resist (we all remember how hard it was to introduce OO API to some extensions why bloat it with OO?). In doubts, we only need to look at all the OO strictness we added in the past versions. Please not that I use we for all php internals developers, as a group (even if we all have different opinions, we reflect only one in our releases). From what I read there is plenty of people that want type hints for static types - there's a few patches out there, it doesn't slow down the general case. So why should we *not* add it? (And yes, I changed my mind) Mines was always in favor of strictness for all types. As it is not necessary to create clean code, it is a really nice addition to bring PHP to yet another good level. Without talking about reducing the WTF in some cases, especially when you have to work in teams with developers not aware of PHP's weirdness (please don't tell me to ask them to RTFM, that's off base). Cheers, -- 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] RE: Optional scalar type hinting
In a way this is true, but I look at it this way. Some languages are strictly typed, some are dynamically typed. PHP can have the best of both worlds by having optional strict typing where desired, as well as I do not believe trying to both eat cake and leave it intact would do us well. Mixing strict and non-strict code would be a nightmare. Absence of static type control (necessary for interpreted language) would make strictly typed code less, and not more stable. Add performance penalty from type checking and effort would be required from PHP newcomers to understand two code models instead of one - and you get the worst of both worlds, not the best. Strict typing allows very little room for type conversion. This is optionally hinting the desired type of a function parameter. That's not what I am hearing here on the list. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thursday 03 January 2008 22:51:27 Stanislav Malyshev wrote: In a way this is true, but I look at it this way. Some languages are strictly typed, some are dynamically typed. PHP can have the best of both worlds by having optional strict typing where desired, as well as I do not believe trying to both eat cake and leave it intact would do us well. Mixing strict and non-strict code would be a nightmare. Absence of static type control (necessary for interpreted language) would make strictly typed code less, and not more stable. Add performance penalty from type checking and effort would be required from PHP newcomers to understand two code models instead of one - and you get the worst of both worlds, not the best. I am not convinced that using type hinting would issue a big performance drawback because of type checking, for the reason that it is already happening. We can already hint types for arrays and objects. And whenever I build function that accepts a scalar value, 90% of the time I have to write a check to make sure the value is acceptable for the operation that occurs inside the function. So no matter what, type checking occurs. And so far I have been able to write lightweight programs when it has suited me, with or without type checking. It is especially in such cases where it would be helpful to skip the test myself, when I know that only the type of variables that I specify can be passed in. It is less and easier coding for me. Also, as this has been mentioned several times already, using type hinting is completely voluntary. Hence, newcomers do not need to bother with it until they are ready to try it out. If it is required in a job, then it hardly matters because it is probably one of the simplest things they might demand from a PHP developer. That's not what I am hearing here on the list. I did not get this comment. Tomi Kaistila PHP Developer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
Stanislav Malyshev schreef: In a way this is true, but I look at it this way. Some languages are strictly typed, some are dynamically typed. PHP can have the best of both worlds by having optional strict typing where desired, as well as I do not believe trying to both eat cake and leave it intact would do us well. Mixing strict and non-strict code would be a nightmare. possibly like the nightmare that namespaces will give us in there current form? I mention it because use of typehinting seems alot more voluntary and less intrusive (when one encounters it in 3rd party code) than namespaces will be. Absence of static type control (necessary for interpreted language) would make strictly typed code less, and not more stable. Add performance penalty from type checking and effort would be required from PHP newcomers to understand two code models instead of one - and you get the worst of newcomers? or newbies? the level of entry is being raised in all sorts of areas whether you like it or not as a by product of making php more suitable to enterprise level development. it's merely a case of not being able to please everyone all of the time (or of not having your cake and eating it) both worlds, not the best. why do we then have typehinting for objects? and more recently arrays? I also seem to remember (forgive me if Im mistaken) that you we're a proponent for the increases in strictness surrounding various things related to OO. that feels rather hypocritical at some level. Strict typing allows very little room for type conversion. This is optionally hinting the desired type of a function parameter. That's not what I am hearing here on the list. you implied in another post that php should have some kind of structured direction. how about a language spec and a formal functionality proprosal/acceptance mechanism? (preferably one that didn't allow major changes like the inclusion of namespaces into a minor release) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 2008-01-03 at 12:51 -0800, Stanislav Malyshev wrote: In a way this is true, but I look at it this way. Some languages are strictly typed, some are dynamically typed. PHP can have the best of both worlds by having optional strict typing where desired, as well as I do not believe trying to both eat cake and leave it intact would do us well. Mixing strict and non-strict code would be a nightmare. Absence of static type control (necessary for interpreted language) would make strictly typed code less, and not more stable. Add performance penalty from type checking and effort would be required from PHP newcomers to understand two code models instead of one - and you get the worst of both worlds, not the best. But this is not all-out strict typing. This is simply checking types on execution of a function. I wrote the patch to follow the exact same model as array type hinting. The only difference is that instead of checking if the value is an array, it checks if it is an integer, string, bool, etc. There aren't two code models here at all. You can have a function parameter, or you can have a type-enforced function parameter. PHP newcomers can just not use type hinting if they want but I don't think this is a valid argument. As for performance, you may have a point. However it is probably no worse than array type hinting, and it's definitely faster than class type hinting, which were both deemed useful for PHP 5.1. Strict typing allows very little room for type conversion. This is optionally hinting the desired type of a function parameter. That's not what I am hearing here on the list. Sorry I don't understand, what is it you are not hearing on the list? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Sam, Jochem,
Sam Barrow wrote:
I think we should stick with E_WARNING for now. If you want to use
exceptions you can throw one in a custom error handler. I can change
about 4 lines of code in my patch to have it emit an E_WARNING easily.
On Thu, 2008-01-03 at 19:49 +0100, Jochem Maas wrote:
am I the only one to consider E_FATAL (as generated for class typehints)
makes
type hinting useless -
I'm currently going down exactly this road. Simplified:
set_error_handler('throwit');
function throwit($code, $msg, $file, $line) {
if (0 == error_reporting()) {
return;
}
throw new Exception($msg in $file on $line, $code);
}
Of course, Jochem, you're right. Exceptions would be nice.
WrongArgumentException, InvalidWhateverException, ...
- - Markus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHfVWT1nS0RcInK9ARApW9AJ9OF+IM/bKWP5D21TDd6r8tTFhNEACgl9Ok
rS+MNouW6p/4C4iKOW3/AlU=
=887G
-END PGP SIGNATURE-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 2008-01-03 at 22:14 +0100, Jochem Maas wrote: Stanislav Malyshev schreef: In a way this is true, but I look at it this way. Some languages are strictly typed, some are dynamically typed. PHP can have the best of both worlds by having optional strict typing where desired, as well as I do not believe trying to both eat cake and leave it intact would do us well. Mixing strict and non-strict code would be a nightmare. possibly like the nightmare that namespaces will give us in there current form? I mention it because use of typehinting seems alot more voluntary and less intrusive (when one encounters it in 3rd party code) than namespaces will be. I don't think any of this stuff will be a nightmare. Maybe for someone who has no idea what they're doing, but in that case programming in any language would be a nightmare. Absence of static type control (necessary for interpreted language) would make strictly typed code less, and not more stable. Add performance penalty from type checking and effort would be required from PHP newcomers to understand two code models instead of one - and you get the worst of newcomers? or newbies? the level of entry is being raised in all sorts of areas whether you like it or not as a by product of making php more suitable to enterprise level development. it's merely a case of not being able to please everyone all of the time (or of not having your cake and eating it) I don't think we should hold back the advancement of PHP and slow down hundreds of experienced developers to accommodate the newcomers. That's like having a universal speed limit of 25mph to accommodate those who don't know how to drive. Learning a language is hard. If a newcomer wants to learn PHP, they will work at it and do it, but keeping PHP at a lower level than what it should be just to make it easier on newcomers is ridiculous. both worlds, not the best. why do we then have typehinting for objects? and more recently arrays? Exactly. It makes no sense to me to introduce type checking for objects, but not for scalar types, when 75% of my variables are integers, strings, booleans, etc, and only about 25% are arrays and objects. I also seem to remember (forgive me if Im mistaken) that you we're a proponent for the increases in strictness surrounding various things related to OO. that feels rather hypocritical at some level. Strict typing allows very little room for type conversion. This is optionally hinting the desired type of a function parameter. That's not what I am hearing here on the list. you implied in another post that php should have some kind of structured direction. how about a language spec and a formal functionality proprosal/acceptance mechanism? (preferably one that didn't allow major changes like the inclusion of namespaces into a minor release) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
I don't get it. We already have type hinting, just not for scalars. The discussion seems to be about whether or not we should have it all. But, the truth is, we have it. We half way have it. I fought for it to be all or nothing back then and I still think it is half done that we don't have scalar type hinting but we have array/object/class type hinting. Talk about inconsistency. So, can we switch the mundane conversation from should we have type hinting to why don't we have scalar type hinting if we have non-scalar type hinting? That is the real conversation. Type hinting is here. It is not going anywhere. Let's finish the job. -- Brian Moon Senior Developer -- When you care enough to spend the very least. http://dealnews.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
So now to use such function you'd have to check your variables for typing - otherwise your application blows up. And the type-checking should be total - otherwise you miss some call to some function or some code path bringing wrong value and your application blows up at runtime - since static type checking is not available. Unless you are aware of the type of your variables and the data they contain as you write your applications, you are only inviting trouble anyway. Yes, PHP handles type juggling on its own but it is not magic wand that makes caring for the data type of your variables meaningless. Meaning, unless all of your code is type-enforced, you'd have to write a wrapper around each type-enforced function manually checking that wrong value didn't get in. But you can do the same checks now, so what is the added value? The one I mentioned not so long ago, or we you not paying attention? Having the type hinted on the function declaration saves me the time and energy of checking the type myself, which is something I have to do quite often. It, of course not, remove the need to validate your arguments completely. But it would be a big help. Tomi Kaistila PHP Developer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
So, can we switch the mundane conversation from should we have type hinting to why don't we have scalar type hinting if we have non-scalar type hinting? That is the real conversation. Type hinting is here. It is not going anywhere. Let's finish the job. Amen. Tomi Kaistila PHP Developer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On 1/4/08, Stanislav Malyshev [EMAIL PROTECTED] wrote:
There aren't two code models here at all. You can have a function
parameter, or you can have a type-enforced function parameter. PHP
So now to use such function you'd have to check your variables for
typing - otherwise your application blows up. And the type-checking
should be total - otherwise you miss some call to some function or some
code path bringing wrong value and your application blows up at runtime
- since static type checking is not available. Meaning, unless all of
your code is type-enforced, you'd have to write a wrapper around each
type-enforced function manually checking that wrong value didn't get in.
But you can do the same checks now, so what is the added value?
type-hinting is asserting.
checking of types is needed only on interface-border points (where
type-hints would be used), but usually can be skipped in a lot points
in private methods
It's good to be sure, that input-value is exactly the one which is
supposed to be there
currently the typical code is:
public function someMethod($var1)
{
if (!is_int($var1)) {
throw new UnexpectedValueException();
}
// …
}
it looks too long and (what is even worse) it hides actual
business-logic behing checks. I prefer the following code:
public function someMethod(integer $var1)
{
// …
}
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
RE: [PHP-DEV] RE: Optional scalar type hinting
The question that pops to my mind by reading this thread is what's wrong with
the following code:
function add(int $a, int $b)
{
return $a + $b;
}
add($_REQUEST['a'], $_REQUEST['b']); // Assume $_REQUEST['a'] == '1' and
$_REQUEST['b'] == '2'.
And the truth is that if I was forced to explicitly cast I would be annoyed. I
can't say I see that
cast as promoting better code or more readable code - It would just clutter the
code and be
annoying. PHP does a lot of type juggling for me, why annoy me all of a sudden?
As for the argument of it's optional the problem with it is that most code
that the average PHP
developer writes is constrained PHP that other PHP developers have already
written, either library
or code base. The feature may be optional for the developer writing the
function or method, but it
is enforced on the developer who's using it. This is exactly where the
direction of the platform
arguments come into play.
So I'm thinking, No.
But then I was thought about it further and thought about this scenario:
$a = some_functions(); // Let's say it returned NULL.
$b = $_REQUEST['b']; // Let's say this is ''.
add($a, $b);
Very bad. Hell I'd like to have some easy way of telling off the developer who
tries to do that to
my function. Enter type hints.
Here are a few more examples:
concatenate(string $str1, string $str2)
{
return $str1 . $str2;
}
concatenate('x', 1); // Great, what's the big deal ?
concatenate(NULL, false); // Hmm...
concatenate($obj1, $obj2); // $obj1 and $obj2 have __toString().
So the bottom line is that it seems to me that what would be really useful is
not strict type
hinting, but more like Juggling hinting. i.e differentiate between an OK
type juggle and a bad
type juggle. Silently perform the first, while emit a small notice or warning
for the later.
Just my... erm, 2$... :-)
A
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
I don't get it. We already have type hinting, just not for scalars. The Type hinting for scalars is different because it disables one of the features of PHP language - conversion of scalar types into each other. So, can we switch the mundane conversation from should we have type hinting to why don't we have scalar type hinting if we have non-scalar type hinting? That is the real conversation. Type hinting is here. It These are different kinds of typing, with different consequences. You do not convert DateTime into PEAR_Soap_Client routinely, nor such conversion can make any sense at all, so distinguishing between them is not the same as making hard distinction between integer and float and string, and disabling conversion between them. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
Unless you are aware of the type of your variables and the data they contain as you write your applications, you are only inviting trouble anyway. Yes, If you think so, you should use statically typed languages, why invite trouble from the start? The one I mentioned not so long ago, or we you not paying attention? Having the type hinted on the function declaration saves me the time and energy of checking the type myself, which is something I have to do quite often. It, of Maybe you should write your code differently, so that you shouldn't check it so often. I just checked in Zend Framework source - which is not a small body of code - is_integer is used in capacity you want to use typehints (i.e. this type or error out) only twice, and in both cases I'm not sure it's needed. is_float is not used even once, and is_string I found used only three times in this way, all IMHO unnecessary since simple (string) would work. It could make at least minimal sense to make it converting - but making it type-strict just makes your application blow up in different, less expected, places without actually saving you any time on coding. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
type-hinting is asserting.
checking of types is needed only on interface-border points (where
With strict checking, that means instead of calling:
foo($bar);
you'd have now to do:
if(is_integer($bar)) {
// stupid foo() call would blow up if passed not integer, so I have
to manually handle it
// oh wait, actually I don't have any way to handle it - I need
foo() to be called to proceed
// so let's just
die(can't call foo() because \$bar is not integer);
}
foo($bar);
Now how it's easier or makes application more stable? What happens if
foo() is changed and now accepts both integers and strings? What happens
if someone forgets to write a wrapper?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
W liście Stanislav Malyshev z dnia czwartek 03 stycznia 2008:
type-hinting is asserting.
checking of types is needed only on interface-border points (where
With strict checking, that means instead of calling:
foo($bar);
you'd have now to do:
if(is_integer($bar)) {
// stupid foo() call would blow up if passed not integer, so I have
to manually handle it
// oh wait, actually I don't have any way to handle it - I need
foo() to be called to proceed
// so let's just
die(can't call foo() because \$bar is not integer);
}
foo($bar);
This code is just a good argument *FOR* type hints. When foo is:
function foo(int $bar) {...}
and you want the code to die if $bar is not integer, then foo($bar) would be
the way to go, without the need for the mess you posted. And if you know that
you have either an int or string representing an integer in $bar, then
foo((integer)$bar) would work just well.
The only problem with the cast is that (integer)'abc' is 0, but it has been so
for a long time and there is no need to change it. is_numeric check solves
the problem.
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
you'd have now to do:
if(is_integer($bar)) {
!is_integer() was meant there of course.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
This code is just a good argument *FOR* type hints. When foo is:
function foo(int $bar) {...}
and you want the code to die if $bar is not integer, then foo($bar) would be
Why would you want it? I wouldn't want my code to die, I would want it
to work.
you have either an int or string representing an integer in $bar, then
foo((integer)$bar) would work just well.
And then how exactly strict typing helps you? You can not control at
development time if everybody uses (integer) or not, since being
interpreted PHP has no static type checking. So only option to find it
out is to leave a minefield behind hoping that testers and not actual
users would be ones who make it blow up. What if testers fail to find it?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Jan 4, 2008 12:23 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
This code is just a good argument *FOR* type hints. When foo is:
function foo(int $bar) {...}
and you want the code to die if $bar is not integer, then foo($bar) would be
Why would you want it? I wouldn't want my code to die, I would want it
to work.
you have either an int or string representing an integer in $bar, then
foo((integer)$bar) would work just well.
And then how exactly strict typing helps you? You can not control at
development time if everybody uses (integer) or not, since being
interpreted PHP has no static type checking. So only option to find it
out is to leave a minefield behind hoping that testers and not actual
users would be ones who make it blow up. What if testers fail to find it?
Check google for all fatal errors we introduced about OO strictness
(or getter/setter) and you will see what does that mean to be unclear
about how strict one should be.
I'm not arguing to force strictness but I would love to have it, on a
per class basis for example (/dream).
--
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] RE: Optional scalar type hinting
W liście Stanislav Malyshev z dnia piątek 04 stycznia 2008:
This code is just a good argument *FOR* type hints. When foo is:
function foo(int $bar) {...}
and you want the code to die if $bar is not integer, then foo($bar) would
be
Why would you want it? I wouldn't want my code to die, I would want it
to work.
You wrote:
With strict checking, that means instead of calling:
foo($bar);
you'd have now to do:
if(is_integer($bar)) {
// stupid foo() call would blow up if passed not integer, so I have
to manually handle it
// oh wait, actually I don't have any way to handle it - I need
foo() to be called to proceed
// so let's just
die(can't call foo() because \$bar is not integer);
}
This shows that you explicitly die() if $bar is not integer. But with strict
type hinting this is unneccessary - the script would automatically die if
$bar was not integer. In other words, with strict scalar type hinting the
above would behave just like
foo($bar)
with the only difference being the error message (in your version you've got
your own error message, automatic script failure would raise some built-in
error - which IMO should be E_RECOVERABLE_ERROR, as E_FATAL gives blano
output on production sites where display_error is 0).
Not that I care if scalar type hinting is implemented or not, I just wanted to
point out that your example is just plain wrong.
you have either an int or string representing an integer in $bar, then
foo((integer)$bar) would work just well.
And then how exactly strict typing helps you?
Here it doesn't help, but is easy to work around if you are sure you know what
you're doing. This is the same workaround that is needed if someone used
if (! is_integer($bar)) {die()}
inside of the foo method.
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
Unless you are aware of the type of your variables and the data they
contain as you write your applications, you are only inviting trouble
anyway. Yes,
If you think so, you should use statically typed languages, why invite
trouble from the start?
It is not inviting trouble. In fact it is a good way of avoiding trouble. If
anything it only encourages discipline when writing code and I have yet to
find a programmer who thinks that is a bad thing.
It is one of the things that often annoys me with php functions is that they
do everything they can to avoid failing. While this saves me from looking at
a E_FATAL error, it also subjects my data to changes that are I cannot know
and often differ from function to function.
What this encourages is careless coding standards, where programmers just
assume that PHP will look after them, which is no doubt one of the reasons
behind the popular myth that PHP encourages sloppy programming.
In the days of PHP 4 there was not much of a choice. The best solution was to
either avoid failing at all cost or return a false value to prevent data from
being twisted. Now we have exceptions which makes failing quickly to prevent
mistakes easy and useful.
Here is a small example of how data can be twisted:
function incr($number)
{
static $total = 0;
$total += $number;
return $total;
}
$n1 = 2; $n2 = '1';
incr($n1);
$n3 = incr($n2);
print $n3;
$n2 is a string value of the number one. What happens if, during a more
complex computation an incorrect value is store to $n2, lets say an
alphabetic character?
The value would be interpreted as a zero and the result would be wrong.
This is just a small example, but hidden among 30,000 lines of code, looking
for it would definitely ruin my day.
Maybe you should write your code differently, so that you shouldn't
check it so often.
I could try that. But then again I have found that the way that I write my
code has produced quality work for which I have been rewarded with satisfied
users. So obviously I am doing something right.
One thing that I will not do is be arrogant enough to assume that because
someone does something differently from me it has to be wrong. If anything is
sure, is that people will use your code for things that you never considered
(note that this is not a bad thing).
I just checked in Zend Framework source - which is
not a small body of code - is_integer is used in capacity you want to
use typehints (i.e. this type or error out) only twice, and in both
cases I'm not sure it's needed. is_float is not used even once, and
is_string I found used only three times in this way, all IMHO
unnecessary since simple (string) would work.
Right... So your argument is that because you guys did not do it with the Zend
Framework, none of us should do it?
It could make at least minimal sense to make it converting - but making
it type-strict just makes your application blow up in different, less
expected, places without actually saving you any time on coding.
Actually it makes less sense to have type hinting as sort of a hidden way to
cast values. Whenever execute operations somewhere the developer cannot see
it, you risk blind-sighting him because one minute he expects only X to
happen and suddenly (usually upon discovering a bug, potentially in
production use) he notices that both X and Y happened.
Tomi Kaistila
PHP Developer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
$n2 is a string value of the number one. What happens if, during a more complex computation an incorrect value is store to $n2, lets say an alphabetic character? The value would be interpreted as a zero and the result would be wrong. If you change data, result changes - surprise! If you set $n2 to 42, result would be wrong too, if by right you mean $n2 being 1 and not 42. How it has anything to do with static typing? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
If you change data, result changes - surprise! If you set $n2 to 42, result would be wrong too, if by right you mean $n2 being 1 and not 42. How it has anything to do with static typing? Ohh gee wiz... Well odds are that you would not want the value to increase by zero, when the intention was to increase with anything but zero. Would type hinting help? Well, it would efficiently assure that the value passed into it was a number and thus the resulted would not get screwed because we assumed PHP's type juggling would save the day. Honestly Stanislav, do you even care or read what people write to or is it your intension only to knit-pick and and be a thicky? Here is the short version for you. Yes, we all agree that there are existing workarounds to having scalar values typed hinted. Just like we could have workarounds for the missing OO features in PHP 4? This does not invalidate the need for either feature. Tomi Kaistila PHP Developer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
The value is this:
With type hinting:
function a(string $mystring, num $mynum, object $myobject) {
}
Without type hinting:
function a($mystring, $mynum, $myobject) {
if (!is_string($mystring)) {
trigger_error('Parameter 1 of function a() must be a string.',
E_USER_WARNING) ;
}
if (!is_int($mynum) and !is_float($mynum)) {
trigger_error('Parameter 2 of function a() must be a number.',
E_USER_WARNING) ;
}
if (!is_object($myobject) {
trigger_error('Parameter 3 of function a() must be an object.',
E_USER_WARNING) ;
}
}
On Thu, 2008-01-03 at 13:51 -0800, Stanislav Malyshev wrote:
There aren't two code models here at all. You can have a function
parameter, or you can have a type-enforced function parameter. PHP
So now to use such function you'd have to check your variables for
typing - otherwise your application blows up. And the type-checking
should be total - otherwise you miss some call to some function or some
code path bringing wrong value and your application blows up at runtime
- since static type checking is not available. Meaning, unless all of
your code is type-enforced, you'd have to write a wrapper around each
type-enforced function manually checking that wrong value didn't get in.
But you can do the same checks now, so what is the added value?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: Optional scalar type hinting
You have a point, but for input in general non type-hinted functions
should be used. Your first example shows a scenario in which not to use
type hinting, because all $_REQUEST input is in string form. However
when dealing with internal functions and methods, type hinting can
prevent flawed interaction between multiple developer's code, as well as
enforce a consistent API.
On Thu, 2008-01-03 at 22:13 +, Amir Abiri wrote:
The question that pops to my mind by reading this thread is what's wrong
with the following code:
function add(int $a, int $b)
{
return $a + $b;
}
add($_REQUEST['a'], $_REQUEST['b']); // Assume $_REQUEST['a'] == '1' and
$_REQUEST['b'] == '2'.
And the truth is that if I was forced to explicitly cast I would be annoyed.
I can't say I see that
cast as promoting better code or more readable code - It would just clutter
the code and be
annoying. PHP does a lot of type juggling for me, why annoy me all of a
sudden?
As for the argument of it's optional the problem with it is that most code
that the average PHP
developer writes is constrained PHP that other PHP developers have already
written, either library
or code base. The feature may be optional for the developer writing the
function or method, but it
is enforced on the developer who's using it. This is exactly where the
direction of the platform
arguments come into play.
So I'm thinking, No.
But then I was thought about it further and thought about this scenario:
$a = some_functions(); // Let's say it returned NULL.
$b = $_REQUEST['b']; // Let's say this is ''.
add($a, $b);
Very bad. Hell I'd like to have some easy way of telling off the developer
who tries to do that to
my function. Enter type hints.
Here are a few more examples:
concatenate(string $str1, string $str2)
{
return $str1 . $str2;
}
concatenate('x', 1); // Great, what's the big deal ?
concatenate(NULL, false); // Hmm...
concatenate($obj1, $obj2); // $obj1 and $obj2 have __toString().
So the bottom line is that it seems to me that what would be really useful is
not strict type
hinting, but more like Juggling hinting. i.e differentiate between an OK
type juggle and a bad
type juggle. Silently perform the first, while emit a small notice or warning
for the later.
Just my... erm, 2$... :-)
A
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
If foo() is changed, the type hints should be removed. Most of the time
however, a function will not change its functionality enough to change
the purpose of the arguments.
On Thu, 2008-01-03 at 14:50 -0800, Stanislav Malyshev wrote:
type-hinting is asserting.
checking of types is needed only on interface-border points (where
With strict checking, that means instead of calling:
foo($bar);
you'd have now to do:
if(is_integer($bar)) {
// stupid foo() call would blow up if passed not integer, so I have
to manually handle it
// oh wait, actually I don't have any way to handle it - I need
foo() to be called to proceed
// so let's just
die(can't call foo() because \$bar is not integer);
}
foo($bar);
Now how it's easier or makes application more stable? What happens if
foo() is changed and now accepts both integers and strings? What happens
if someone forgets to write a wrapper?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, Jan 03, 2008 at 10:13:22PM -, Amir Abiri wrote:
So the bottom line is that it seems to me that what would be really useful is
not strict type
hinting, but more like Juggling hinting. i.e differentiate between an OK
type juggle and a bad
type juggle. Silently perform the first, while emit a small notice or warning
for the later.
+1
But silently perform the juggle on the value when it enters the function, so it
does not
need to be done many times again:
function SumToN(int $n)
{
for($tot = 0; $n 0; $n--)
$tot += $n;
return $n;
}
$total = SumToN(10);// Perform check and then silent juggle
$total = SumToN(10); // Perform check but juggle not needed
$total = SumToN(ten); // Perform check and emit an error (somehow)
The error is better emitted at the point of function call rather than having
to put a check within SumToN()
--
Alain Williams
Linux 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
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] RE: Optional scalar type hinting
It doesn't disable type conversion unless you specifically tell it to. Plus the fact that if it issues an E_WARNING, your application will not necessarily stop execution. On Thu, 2008-01-03 at 14:30 -0800, Stanislav Malyshev wrote: I don't get it. We already have type hinting, just not for scalars. The Type hinting for scalars is different because it disables one of the features of PHP language - conversion of scalar types into each other. So, can we switch the mundane conversation from should we have type hinting to why don't we have scalar type hinting if we have non-scalar type hinting? That is the real conversation. Type hinting is here. It These are different kinds of typing, with different consequences. You do not convert DateTime into PEAR_Soap_Client routinely, nor such conversion can make any sense at all, so distinguishing between them is not the same as making hard distinction between integer and float and string, and disabling conversion between them. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, Jan 03, 2008 at 07:36:48PM +0100, Markus Fischer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Alain Williams wrote: On Thu, Jan 03, 2008 at 12:21:21PM -0500, Sam Barrow wrote: I think E_WARNING would be appropriate. That's what happens when you omit an argument to a function right? The other thing to note about type hinting is that it could result in faster code. The value is checked and if needed converted (eg string - integer) when the function is called; it then need not be converted again when it is used in the function. This will presumably be a win if the value is used more than once. I don't think that automagic conversion of types is a good idea. When the type hint says I want an integer, then only integer should be accepted; no casting should be done. It may give predictable results Maybe the type checks should be stricter than normal. What are we going to want here ? * integer - possibly convert from: - string, in which case we just accept digits with an option + or - The important thing is that the *entire* string must convert - float - the standard truncate towards zero Nothing else * float - possibly convert from: - integers - standard convertion - string - accept a float in the standard formats The important thing is that the *entire* string must convert * boolean. At first glance this is easier as the convert to boolean for lots of types is well defined. In most cases the programmer would not be interested in a type check, so if he specifies it then we should be very restrictive. * string - possibly convert from: - integers float - standard convertion - boolean - standard convertion - objects - only if they have a __toString() method -- Alain Williams Linux 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 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] RE: Optional scalar type hinting
On Thu, Jan 03, 2008 at 10:43:39AM -0800, Stanislav Malyshev wrote: When the type hint says I want an integer, then only integer should be accepted; no casting should be done. It may give predictable results Why people that want Java just don't use Java I wonder? PHP never was a strict static typed language. You aren't making it a strict static typed language. All that you are doing is saying that at certain points (function entry) that the values are checked and converted to certain types. If within the fuction an argument hinted as integer is used in a string context, the juggling will still happen. What you are doing to allowing the function author to protect the integrity of his code without having to resort to a regex/... to check what the arguments are. -- Alain Williams Linux 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 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] RE: Optional scalar type hinting
On Thu, Jan 03, 2008 at 03:14:37PM -0500, Sam Barrow wrote: On Thu, 2008-01-03 at 13:00 -0700, John Coggeshall wrote: Wouldn't this patch also allow for additional performace optimizations which would help counter losses even in the non-general case? Performance optimizations in what way? I gave an example in another post. Summary: the argument value is check to be (say) numeric on function entry, if it is not numeric but can be converted to a number (eg it is a string of digits) then the convertion is done on function entry. If the value is used several times within the code (presumably as a number) then the type juggle 'string of digits - number' will not need to be done since it was done on function entry. -- Alain Williams Linux 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 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] RE: Optional scalar type hinting
You aren't making it a strict static typed language. All that you are doing is saying that at certain points (function entry) that the values are checked and converted to certain types. If within the fuction an argument hinted as integer is used in a string context, the juggling will still happen. So it's basically another way to say (string)? Again, that's not what was said by other people discussing it. But all that just to save one (string) inside function? What you are doing to allowing the function author to protect the integrity of his code without having to resort to a regex/... to check what the arguments are. If you need regex, you'd still have to use regex. Type juggling can do only so much. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stanislav Malyshev wrote: You aren't making it a strict static typed language. All that you are doing is saying that at certain points (function entry) that the values are checked and converted to certain types. If within the fuction an argument hinted as integer is used in a string context, the juggling will still happen. So it's basically another way to say (string)? Again, that's not what was said by other people discussing it. But all that just to save one (string) inside function? I agree with Stanislav here. For me type hinting has nothing to do with type conversion. Hinting a 'string' expects a string, nothing else, not even an object. If you need this, you need to call the function/method with an explicit conversion. It's a less 'wtf' factor going on. - - Markus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfYjI1nS0RcInK9ARAvEwAKC0WhOjaogX+f84rQArW5s071fSDgCgriWl 1+JM1RK46VVFL7Bz8pjjID0= =ORed -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
For me type hinting has nothing to do with type conversion. Hinting a 'string' expects a string, nothing else, not even an object. Agreed. It seems like a way to compromise between those who support this feature and those who do not, but in a way that completely defeats the purpose of type hinting. Tomi Kaistila PHP Developer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Fri, 2008-01-04 at 02:01 +, Steph wrote: I'm just a php developer who didn't agree with the rules on type hinting. ... or superglobals, or multiple class inheritance rules. Why PHP? What did we do? :\ More seriously (because I don't think this has a hope in hell of getting in, for all the reasons Stas is trying to explain) - I'm bothered because I idly went to check you out when you first turned up and couldn't find any record of your existence prior to your appearance on [EMAIL PROTECTED] Even the site name's booked by proxy. Are you the Brackets man? I just like PHP enough that rather than switch languages, I would like to attempt to make PHP better. I've only been working with the PHP source since November and I'm 19 so I haven't been around for many prior contributions to PHP; that's probably why you haven't heard of me. I started messing with the source and about a week later I had the type hinting and superglobal patches done, and I joined internals. I completely understand the disadvantages to multiple inheritance so I've kind of dropped that, I support custom superglobals but I can understand why they are unwanted, but scalar type hinting I think should be in PHP. I have written all 3 of these patches but this is the one I'm pushing for mostly. I'm using the superglobal patch for my own development, and I have multiple inheritance working, but I don't want to have to rewrite the patch every time php changes. And these reasons you're talking about that Stas brought up, I don't see any reasons besides the fact that it may confuse newcomers and it's too javaish. Performance is not an issue here, especially for those who don't use type hinting. For those who don't want to use it they don't have to because it's optional. Any other arguments can be countered by the fact that if type hinting is not proper in the situation, don't use it. If you want to, then use it. Everybody wins. Plus the majority on here seems to agree with me. Type hinting is already in PHP. It's been in PHP. Why not add a couple of useful types? I don't see any debate here. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
I just like PHP enough that rather than switch languages, I would like to attempt to make PHP better. I've only been working with the PHP source since November and I'm 19 Right, that'd explain it. It's just that usually people do a bit of PHP development (websites, applications, whatever) or throw out a couple of classes, or _something_ that Google can find anyways, before they start telling the core PHP dev team they're doing it all wrong. so I haven't been around for many prior contributions to PHP; that's probably why you haven't heard of me. I started messing with the source and about a week later I had the type hinting and superglobal patches done, and I joined internals. No, you subscribed to the internals mailing list. I completely understand the disadvantages to multiple inheritance so I've kind of dropped that, I support custom superglobals but I can understand why they are unwanted, but scalar type hinting I think should be in PHP. I have written all 3 of these patches but this is the one I'm pushing for mostly. I'm using the superglobal patch for my own development, and I have multiple inheritance working, but I don't want to have to rewrite the patch every time php changes. So far, fair enough. And these reasons you're talking about that Stas brought up, I don't see any reasons besides the fact that it may confuse newcomers and it's too javaish. 'It may confuse newcomers' is a big issue in PHP. Ease of takeup is the mainspring of the language's design. The other point Stas made that you appear to have missed is that loose typing is very much a PHP feature. It's one of the things that helps make the language easy for newcomers, and it also means the language is more forgiving than others. OO is a different matter because you get different *types* of objects. You don't get different *types* of strings, integers or floats, or at least, not to the same degree. People using PHP shouldn't have to know about those differences unless they really need to. Performance is not an issue here, especially for those who don't use type hinting. For those who don't want to use it they don't have to because it's optional. It's optional, sure, but it's one more thing that every newbie will need to be aware of before s/he can call himself a PHP developer. Every one of those optional features that is added to the language is another barrier against takeup. Any other arguments can be countered by the fact that if type hinting is not proper in the situation, don't use it. If you want to, then use it. Everybody wins. Plus the majority on here seems to agree with me. Type hinting is already in PHP. It's been in PHP. Why not add a couple of useful types? I don't see any debate here. You, a handful of list lurkers, Jochem hanging in there for his one-man-crusade (he wants to formalize PHP core development so much that nobody will do it for pleasure ever again), Derick inexplicably backing you. Nobody else even bothering to argue because Stas seems to be doing the job fairly well all by himself right now. Johannes quite rightly won't introduce type hinting for scalars without a mandate, and there doesn't appear to be one right now. If it _is_ accepted it'll most likely be in PHP 6 not 5.3 anyway, because 5.3's features were agreed (and limited) a couple of months ago. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Fri, 2008-01-04 at 02:56 +, Steph wrote: I just like PHP enough that rather than switch languages, I would like to attempt to make PHP better. I've only been working with the PHP source since November and I'm 19 Right, that'd explain it. It's just that usually people do a bit of PHP development (websites, applications, whatever) or throw out a couple of classes, or _something_ that Google can find anyways, before they start telling the core PHP dev team they're doing it all wrong. Time out. I didn't say anyone was doing it all wrong. And I've been developing in PHP for about 4 years. I am Zend certified and I have a full time job developing in PHP with people twice my age and years of experience. Not at all bragging, but I am far from the beginner who's speaking what he doesn't know. Just because my code isn't on google doesn't mean I haven't done any. If you want to see some stuff I've done just let me know I will gladly send it to you. Plus the fact that I'm obviously not stupid and I have some idea what I'm doing if I am writing patches for the PHP core with no prior experience. so I haven't been around for many prior contributions to PHP; that's probably why you haven't heard of me. I started messing with the source and about a week later I had the type hinting and superglobal patches done, and I joined internals. No, you subscribed to the internals mailing list. Ok, wording mistake. I completely understand the disadvantages to multiple inheritance so I've kind of dropped that, I support custom superglobals but I can understand why they are unwanted, but scalar type hinting I think should be in PHP. I have written all 3 of these patches but this is the one I'm pushing for mostly. I'm using the superglobal patch for my own development, and I have multiple inheritance working, but I don't want to have to rewrite the patch every time php changes. So far, fair enough. And these reasons you're talking about that Stas brought up, I don't see any reasons besides the fact that it may confuse newcomers and it's too javaish. 'It may confuse newcomers' is a big issue in PHP. Ease of takeup is the mainspring of the language's design. The other point Stas made that you appear to have missed is that loose typing is very much a PHP feature. It's one of the things that helps make the language easy for newcomers, and it also means the language is more forgiving than others. OO is a different matter because you get different *types* of objects. You don't get different *types* of strings, integers or floats, or at least, not to the same degree. People using PHP shouldn't have to know about those differences unless they really need to. Ok then. This is understood, that's why newcomers shouldn't use type hinting. Are you saying we should hold back new features because they might confuse beginners? I used PHP for quite a while before using any object oriented stuff. When I was ready, I started doing object oriented programming. Also, I didn't say we should throw away loose typing. This is not at all strict typing. This is optionally type hinting specified function arguments. There is a big difference. Performance is not an issue here, especially for those who don't use type hinting. For those who don't want to use it they don't have to because it's optional. It's optional, sure, but it's one more thing that every newbie will need to be aware of before s/he can call himself a PHP developer. Every one of those optional features that is added to the language is another barrier against takeup. How complicated is it? Is it any worse than array type hinting? Should we sacrifice functionality in order to make it as easy as possible to master PHP? Programming is hard. If you have enough intelligence to call yourself a PHP Developer then you can surely understand the difference between an integer and a string. Any other arguments can be countered by the fact that if type hinting is not proper in the situation, don't use it. If you want to, then use it. Everybody wins. Plus the majority on here seems to agree with me. Type hinting is already in PHP. It's been in PHP. Why not add a couple of useful types? I don't see any debate here. You, a handful of list lurkers, Jochem hanging in there for his one-man-crusade (he wants to formalize PHP core development so much that nobody will do it for pleasure ever again), Derick inexplicably backing you. Nobody else even bothering to argue because Stas seems to be doing the job fairly well all by himself right now. Johannes quite rightly won't introduce type hinting for scalars without a mandate, and there doesn't appear to be one right now. If it _is_ accepted it'll most likely be in PHP 6 not 5.3 anyway, because 5.3's features were agreed (and limited) a couple of months ago. Ok, if you say so. But I see many PHP developers/users pushing for type hinting.
Re: [PHP-DEV] RE: Optional scalar type hinting
On Fri, 2008-01-04 at 02:56 +, Steph wrote: I just like PHP enough that rather than switch languages, I would like to attempt to make PHP better. I've only been working with the PHP source since November and I'm 19 Right, that'd explain it. It's just that usually people do a bit of PHP development (websites, applications, whatever) or throw out a couple of classes, or _something_ that Google can find anyways, before they start telling the core PHP dev team they're doing it all wrong. I do have one site live - www.ubuntuhcl.org. I made this quite a while ago, not the best coding methods because this was when I had much less experience but a fully functional site I made form scratch. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
snip / That wasn't what I meant, I'm sorry if it came over that way. I used PHP for quite a while before using any object oriented stuff. When I was ready, I started doing object oriented programming. That's pretty normal :) Also, I didn't say we should throw away loose typing. This is not at all strict typing. This is optionally type hinting specified function arguments. There is a big difference. There is and there isn't. Say you're a junior developer in your first job, if your team happens to use that option and you never used it before in your life, how steep is your learning curve going to be? How complicated is it? Is it any worse than array type hinting? Should we sacrifice functionality in order to make it as easy as possible to master PHP? How is it sacrificing functionality? Personally I'm totally unconvinced of the need for type hinting beyond object considerations; array type hinting was a step towards the breach for me. You see it the entirely opposite way. Who's right or wrong isn't the real issue here; it's more a case of who's right _at this moment in time, for this language and for its users_. I see a language that became successful because it is easily learned. You see a language that isn't successful enough because it doesn't do... what? (This is the point I'm failing to grasp.) Either way, any new features agreed on the list this month aren't likely to be part of standard PHP development practice for literally years, so we're also both guessing wildly at what will or won't have been the right decision 5 years from now. Programming is hard. If you have enough intelligence to call yourself a PHP Developer then you can surely understand the difference between an integer and a string. Because you can doesn't mean you should. The web doesn't know that difference. Ok, if you say so. But I see many PHP developers/users pushing for type hinting. Even if I was a naive list lurking PHP beginner who has only written a couple of classes, I am not necessarily wrong because of it. I agree with you there. I do, however, think that on the internals list it'd be more to the point to hear from internals developers on the matter. Raise issues by all means, but what's actually happening in this case is that we've heard from 3 internals developers (I missed Pierre's mail earlier) in a thread that has gathered over 60 emails in - in my timezone - a single evening. Most of the dev team won't have time to read such a long thread... - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: Optional scalar type hinting
We've discussed scalar type hinting many times in the past and decided against it. It really doesn't fit in very well with PHP's loosely typed nature which is one of the main reasons it has been so easy to use. The only reason why it works with classes and arrays is because those are unambiguous constructs. Even this thread shows that there's no alignment between people on what it should actually do. This is due to the lose nature of PHP. For example, HTTP vars come in as strings. So if you have http://localhost/?n=1 in your URL there are some in this thread which would expect it to be successfully juggled by an int type hint even though it actually comes in as a string; and some who want it to be ultra-strict and if the PHP type isn't an integer it should emit an error. What happens when you pass an object with a __toString() method to a function expecting a string? I think it should work and convert. I am sure some here disagree. This is exactly the problem! Saying that it won't confuse newbies is also wrong. PHP is so popular because it's so easy for people to pick up. Part of this also includes ability to look at other people's code, understand it, copy-on-write (e.g. a Wordpress plug-in). The more features in PHP the harder it'll be for developers to deal with. Yes, we bit the bullet for namespaces because there were strong reasons in favor of it, we as a community had it on our wishlist for a long time and a lot of work went into it. And even when we did it we had to find a way to make it work for PHP. In this case, with the lose typing of PHP creating a consistent model which will be apparent to people without many questions is a big issue. Also, for those who say that when this feature is not used it doesn't have a performance impact that is also a problematic statement. If it exists people will use it. Most people using PHP don't understand (and shouldn't have to understand) how the language is implemented. It may very well be that even if we could agree on the semantics we'll see all sorts of developers decorate their code with type hints (because they think it'll help readability) who may down the road find themselves in a surprise when it comes to performance. Last, just because something can be implemented and a patch exists doesn't mean it should be in PHP. There are lots of things I can implement for PHP which shouldn't be in PHP. Also don't under estimate what happens when you get bloatware and over time how much harder it becomes to maintain and also how it does eventually end up slowing things down (over time there are more branches, more code a.k.a more cache misses, etc...) We have what I think is a very exciting PHP version coming up with 5.3. The featureset has been agreed upon. It'd be great if all the contributing energy in this thread could be channeled towards playing around with 5.3 esp. the new i18n extension, namespaces, help with migration/incompatibility notes and garbage collector benchmarks. We are now at the stage where we really need the code base to mature with feedback from users. The more you can invest in that the better. Ouch, sorry for the long email! :'( Andi P.S.- The runtime piece of this patch also looks wrong. I didn't dive deep but those if() statements don't look too friendly. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
