All,
I think that we should revisit the options on the table. I have a
feeling that much like many people didn't realize they're voting to
bring this into 5.3 - many weren't fully aware of the options on the
table and their implications (to be clear - I'm sure some were, but I
think many were not).
The options as I see them:
-
Do nothing. I think the vote established that this is not what
people want. -
Move forward with the semantics of the current patch. This
approach has substantial drawbacks in my opinion, and is a strong
misfit with the rest of PHP (again, in my opinion). See previous
posts from Stas, Rasmus, myself and maybe others illustrating this
point. Lukas's 'Strict and Weak Typing RFC'
(http://wiki.php.net/rfc/typecheckingstrictandweak) has some good
insight as to why strict typing is problematic in PHP. -
Implement 'weak' typing. What does that mean? Conversion rules
will be very similar to those for internal functions, but slightly
stricter (like I said, if we were to rewrite the conversion rules for
internal functions today - we'd probably make them slightly stricter,
too). For example, if you denote that an argument is supposed to be
an integer, then a string that looks like an integer (e.g. "17")
would be silently converted to an integer, however, a string that
does not look like an integer (e.g. "foo") will error out. We need
to come up with a complete pass/fail table, but that would be the
theme. Unlike option #2, this fits the rest of PHP quite well
(except for minor inconsistencies with internal functions - but these
are dwarfed in comparison to the inconsistencies of option #2).
Two other issues that we need to revisit:
- Agree on when it will be implemented - I think it's pretty clear
it should not go to 5.3. - Make sure people understand why we're implementing it -
performance is certainly not the reason.
Before moving ahead with votes or committing the code, I suggest we
focus on the pros & cons of options #2 and #3. Since the
inconsistencies introduced by option #2 are very substantial (between
internal and userland functions, and also how values behave in PHP in
general), I suggest we focus on use cases where option #2 would be
truly needed and superior to option #3. In other words - what is the
added value and is it worth the price?
I think we can take Lukas's RFC and either change it or write
something based on it for weak typing only. If people here find it
useful I'll go ahead and do that.
Zeev
Hi Zeev,
I've been keeping a very close eye, and have taken part in a good few
discussions, including putting my own idea on the table.
The options as I see them:
- Do nothing. I think the vote established that this is not what people
want.
Agreed.
- Move forward with the semantics of the current patch. This approach has
substantial drawbacks in my opinion, and is a strong misfit with the rest of
PHP (again, in my opinion). See previous posts from Stas, Rasmus, myself
and maybe others illustrating this point. Lukas's 'Strict and Weak Typing
RFC' (http://wiki.php.net/rfc/typecheckingstrictandweak) has some good
insight as to why strict typing is problematic in PHP.
I believe nearly all opinions voiced have wanted the current patch.
Many more were in favour of strict typing only, but for the few
dissenters, like myself, Ilia included casting semantics using (int)
syntax.
There are I think maybe 5 or 6 people who have expressed opinions
against this. All others have been pro (I'm not counting the vote
here, I'm looking at discussions).
- Implement 'weak' typing. What does that mean? Conversion rules will be
very similar to those for internal functions, but slightly stricter (like I
said, if we were to rewrite the conversion rules for internal functions
today - we'd probably make them slightly stricter, too). For example, if
you denote that an argument is supposed to be an integer, then a string that
looks like an integer (e.g. "17") would be silently converted to an integer,
however, a string that does not look like an integer (e.g. "foo") will error
out. We need to come up with a complete pass/fail table, but that would be
the theme. Unlike option #2, this fits the rest of PHP quite well (except
for minor inconsistencies with internal functions - but these are dwarfed in
comparison to the inconsistencies of option #2).
This seems like a good idea, but others disagree. I wrote a set of
rules for this, which are very much how you describe them: slightly
stricter than casting, but weaker than strict typing. In the
discussion, there was very little support, and so I withdrew it.
Two other issues that we need to revisit:
- Agree on when it will be implemented - I think it's pretty clear it
should not go to 5.3.
The last discussion certainly made this clear. It should be cleared up
whether people want this is 5.4 (if it happens). I think its
established that people want this in 6.
- Make sure people understand why we're implementing it - performance is
certainly not the reason.
I believe there was only two misguided souls who believed this would
lead to better performance. Everyone else wanted it on its merits.
Before moving ahead with votes or committing the code, I suggest we focus on
the pros & cons of options #2 and #3. Since the inconsistencies introduced
by option #2 are very substantial (between internal and userland functions,
and also how values behave in PHP in general), I suggest we focus on use
cases where option #2 would be truly needed and superior to option #3. In
other words - what is the added value and is it worth the price?
It doesnt sound like you are aware of the casting semantics that Ilia
added. They are largely consistent with the internal function
semantics.
function x (int x) { /* fail on non-int / }
function x ((int) x) { / cast parameter to an int */ } // just like
internals functions
Indeed this adds the ability to make your function work like an
internals function (useful perhaps for library interfaces).
I think we can take Lukas's RFC and either change it or write something
based on it for weak typing only. If people here find it useful I'll go
ahead and do that.
I believe people don't want this. I wrote a set of rules, Lukas wrote
the RFC, and neither got anything like the support that strict typing
got.
One large problem is that it introduced a new 3rd set of rules, and
this set is not intuitive but rather slightly subjective (reasonable
people might disagree on whether a bool should be weakly converted to
an int, for example). The strict type checks are at least simple, and
the current weak ones are what people are used to.
Obviously I'm not against discussion, but we just had this discussion.
Thanks,
Paul
--
Paul Biggar
paul.biggar@gmail.com
At 11:39 09/07/2009, Paul Biggar wrote:
I believe nearly all opinions voiced have wanted the current patch.
Many more were in favour of strict typing only, but for the few
dissenters, like myself, Ilia included casting semantics using (int)
syntax.
I think that many of the people who expressed
support for that patch did not fully realize its
implications - much in the same way they weren't
quite realizing they're actually voting for
inclusion in PHP 5.3. I believe that if we had a
'clean' Weak typing RFC as well as a Strict
typing RFC, each with its pros and cons - there
would be very different results.
There are I think maybe 5 or 6 people who have expressed opinions
against this. All others have been pro (I'm not counting the vote
here, I'm looking at discussions).
I think you're right, but I also think it had to
do with dynamics more than with actual content.
The two approaches were never compared
head-to-head, with the pros and cons - and more
importantly - with use cases on why strict typing
is necessary despite the fact it's fairly 'alien' to PHP.
- Â Make sure people understand why we're
implementing it - performance is
certainly not the reason.I believe there was only two misguided souls who believed this would
lead to better performance. Everyone else wanted it on its merits.
Maybe - but the only way to make sure is to make it a clear part of the RFC(s).
It doesnt sound like you are aware of the casting semantics that Ilia
added. They are largely consistent with the internal function
semantics.function x (int x) { /* fail on non-int / }
function x ((int) x) { / cast parameter to an int */ } // just like
internals functions
I am - and I think I like this even less than
pure strict typing because of increased WTF factor.
I think strict typing is wrong for PHP, and this
cannot be fixed by also adding something
else. The way to 'fix' this is by not adding
strict typing, and adding only weak typing.
Indeed this adds the ability to make your function work like an
internals function (useful perhaps for library interfaces).
If improved with slightly more intrusive checks
(like the ones suggested in my email) - then it
can be useful in mostly all of the places where strict typing would be used.
I think we can take Lukas's RFC and either change it or write something
based on it for weak typing only. Â If people here find it useful I'll go
ahead and do that.I believe people don't want this. I wrote a set of rules, Lukas wrote
the RFC, and neither got anything like the support that strict typing
got.
This could be for a variety of reasons - one of
them is that people truly thought this through
and truly prefer strict typing to weak
typing. But that is just one of the
options. Another is that the difference between
the two approaches, as well as the issues with
strict typing - aren't fully understood by the
audience - and I believe that this is actually the case.
One large problem is that it introduced a new 3rd set of rules, and
this set is not intuitive but rather slightly subjective (reasonable
people might disagree on whether a bool should be weakly converted to
an int, for example). The strict type checks are at least simple, and
the current weak ones are what people are used to.
I definitely don't think we should add two new
semantics. Ideally we shouldn't add any
entirely-new semantics, and what I'm proposing is
to actually reuse the existing semantics for
internal functions - with very minor
modifications. Kind of like Semantics and
Semantics', rather than Sematnics1, Semantics2, Semantics3.
Obviously I'm not against discussion, but we just had this discussion.
Given the implications of introducing something
like that (that can easily grow in the future to
other parts of PHP) - and my belief that the
discussion missed key ingredients, we should discuss it further.
We need to go back to the fundamentals - and look
for use cases where strict typing would be
substantially superior to weak typing. As far as
reflection, code readability, optimization and
security is concerned - I can't find any
superiority, but maybe I'm missing something. We
already have an RFC that details the
disadvantages of strict typing (Lukas's
RFC). Let's focus on the advantages and see if they're worth it?
Zeev
I believe that
if we had a 'clean' Weak typing RFC as well as a Strict typing RFC, each
with its pros and cons - there would be very different results.The two approaches were never compared head-to-head, with the pros and cons
Another is that the difference between the
two approaches, as well as the issues with strict typing - aren't fully
understood by the audience - and I believe that this is actually the case.the
discussion missed key ingredients, we should discuss it further.
I think you are right that the discussions weren't sufficiently clear,
and this could be resolved by better RFCs. This is obviously how it
should have been done in the first place (look at the success of
Python's PEPs).
I'm not sure this will change things, and worry it might derail what
we have now, but those are not good reasons to stop the discussion.
Thanks,
Paul
--
Paul Biggar
paul.biggar@gmail.com
-----Oorspronkelijk bericht-----
Van: Zeev Suraski [mailto:zeev@zend.com]
Verzonden: donderdag 9 juli 2009 11:46
Aan: Paul Biggar
CC: internals@lists.php.net
Onderwerp: Re: [PHP-DEV] Type hinting - Request for DiscussionAt 11:39 09/07/2009, Paul Biggar wrote:
I believe nearly all opinions voiced have wanted the current patch.
Many more were in favour of strict typing only, but for the few
dissenters, like myself, Ilia included casting semantics using (int)
syntax.I think that many of the people who expressed
support for that patch did not fully realize its
implications - much in the same way they weren't
quite realizing they're actually voting for
inclusion in PHP 5.3. I believe that if we had a
'clean' Weak typing RFC as well as a Strict
typing RFC, each with its pros and cons - there
would be very different results.There are I think maybe 5 or 6 people who have expressed opinions
against this. All others have been pro (I'm not counting the vote
here, I'm looking at discussions).I think you're right, but I also think it had to
do with dynamics more than with actual content.
The two approaches were never compared
head-to-head, with the pros and cons - and more
importantly - with use cases on why strict typing
is necessary despite the fact it's fairly 'alien' to PHP.
- Â Make sure people understand why we're
implementing it - performance is
certainly not the reason.I believe there was only two misguided souls who believed this would
lead to better performance. Everyone else wanted it on its merits.Maybe - but the only way to make sure is to make it a clear part of the
RFC(s).It doesnt sound like you are aware of the casting semantics that Ilia
added. They are largely consistent with the internal function
semantics.function x (int x) { /* fail on non-int / }
function x ((int) x) { / cast parameter to an int */ } // just like
internals functionsI am - and I think I like this even less than
pure strict typing because of increased WTF factor.
I think strict typing is wrong for PHP, and this
cannot be fixed by also adding something
else. The way to 'fix' this is by not adding
strict typing, and adding only weak typing.Indeed this adds the ability to make your function work like an
internals function (useful perhaps for library interfaces).If improved with slightly more intrusive checks
(like the ones suggested in my email) - then it
can be useful in mostly all of the places where strict typing would be
used.I think we can take Lukas's RFC and either change it or write
something
based on it for weak typing only. Â If people here find it useful
I'll go
ahead and do that.I believe people don't want this. I wrote a set of rules, Lukas wrote
the RFC, and neither got anything like the support that strict typing
got.This could be for a variety of reasons - one of
them is that people truly thought this through
and truly prefer strict typing to weak
typing. But that is just one of the
options. Another is that the difference between
the two approaches, as well as the issues with
strict typing - aren't fully understood by the
audience - and I believe that this is actually the case.One large problem is that it introduced a new 3rd set of rules, and
this set is not intuitive but rather slightly subjective (reasonable
people might disagree on whether a bool should be weakly converted to
an int, for example). The strict type checks are at least simple, and
the current weak ones are what people are used to.I definitely don't think we should add two new
semantics. Ideally we shouldn't add any
entirely-new semantics, and what I'm proposing is
to actually reuse the existing semantics for
internal functions - with very minor
modifications. Kind of like Semantics and
Semantics', rather than Sematnics1, Semantics2, Semantics3.Obviously I'm not against discussion, but we just had this discussion.
Given the implications of introducing something
like that (that can easily grow in the future to
other parts of PHP) - and my belief that the
discussion missed key ingredients, we should discuss it further.We need to go back to the fundamentals - and look
for use cases where strict typing would be
substantially superior to weak typing. As far as
reflection, code readability, optimization and
security is concerned - I can't find any
superiority, but maybe I'm missing something. We
already have an RFC that details the
disadvantages of strict typing (Lukas's
RFC). Let's focus on the advantages and see if they're worth it?Zeev
I am a long time (passive) list reader but seeing the direction of this
discussion makes me feel obligated to express my opinion.
I'm a framework developer and I have great interest in type hinting/casting.
I'm all for clarity and strictness, but it should definitely be a choice.
PHP is known for its easy learning curve, that is one of its big powers and
that should remain unchanged. But the way I see it is that it can be
implemented without requiring you to use it, if you want to use type
hinting/casting go ahead, if you don't want it, well, leave that bit alone.
If it comes with a minor performance hit, OK, i can live with that, I agree
with Lukas in that aspect, you don't spend lots of time checking/casting
anyway.
As for hinting/casting would not be 'php-ish', i don't see it that way, i
look at php as a language of possibilities, not restrictions.
As I said, i'm a framework developer and it would greatly improve
readability, usability and quality when you can use type hinting/casting.
Consider a pretty common architecture where you have a service layer which
does validation and stuff and then passes control to 'deeper' parts in the
framework. Your service layer could have a casting hint, while the more
inner components could have a strict hint. There you can trust the data is
of the type you wanted, otherwise there is something wrong anyway.
The most important thing is that it is optional, you have the choice to
use it.
Regarding syntax, to me it is totally intuitive that foo((int) $bar) tries
to do a cast and foo(int $bar) is strict, it's also easy to explain to
students, put parenthesis around your type name and it's a cast, whether it
is in an assignment or a method declaration it doesn't matter.
Seeing the discussion I think there is consensus it shouldn't be in 5.3. I
think it shouldn't be in 5.x total, the 5.x branch is already loaded with
lots of new cool stuff and in my opinion all focus should be on getting a
6.0 release asap.
I know, i'm 'just' a php user but maybe I can inspire someone in taking the
'right' course.
Regards,
Dennis Haarbrink
Hi Dennis,
The most important thing is that it is optional, you have the choice to
use it.
Sorry to go a little bit off-topic, but this idea has been bandied
around a lot over the last week, and I'd like to respond to it.
Although the proposed checks are optional, nobody has a "choice" to
use a new language feature. Though you may choose not to use a feature
in your code for whatever reason, it will appear in code from your
colleagues, clients, or upstream libraries. Every feature in PHP will
at some point be put in front of every PHP developer.
As a result, the argument that "you dont like it, so what, you have a
choice not to use it", is simply incorrect. Though at some point the
majority may have to overrule the views of the minority, please do not
dismiss them out of hand with this logic.
Thanks,
Paul
--
Paul Biggar
paul.biggar@gmail.com
Hi Paul,
-----Oorspronkelijk bericht-----
Van: Paul Biggar [mailto:paul.biggar@gmail.com]
Verzonden: donderdag 9 juli 2009 13:03
Aan: Dennis Haarbrink
CC: internals@lists.php.net
Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion
Although the proposed checks are optional, nobody has a "choice" to
use a new language feature. Though you may choose not to use a feature
in your code for whatever reason, it will appear in code from your
colleagues, clients, or upstream libraries. Every feature in PHP will
at some point be put in front of every PHP developer.
I don't think this is a really valid argument.
I mean, libraries may have all kinds of quirks, you may not be satisfied with the supplied API or maybe even the entire philosophy behind it, but that shouldn't stop you from using it or is it?
Regards,
Dennis Haarbrink
I mean, libraries may have all kinds of quirks, you may not be satisfied with the supplied API or maybe even the entire philosophy behind it, but that shouldn't stop you from using it or is it?
You must learn what these quirks are. Likewise, every developer must
learn the quirks of the "type hinting" as they will almost certainly
be required to interact with code that uses it.
In an extreme case, suppose that we completely balls-ed up the
semantics of type checks to be really really hard to use, but people
used them anyway. That would lead to a sharp learning curve. The
people who are against this proposal, or any other, know they will be
required to use it when it comes in, and have an interest in making
sure it is clean (whatever that means in each case). We shouldn't
dismiss their objections on the argument that they arent required to
use it. If its in the language, they are required to learn it.
Paul
--
Paul Biggar
paul.biggar@gmail.com
-----Oorspronkelijk bericht-----
Van: Paul Biggar [mailto:paul.biggar@gmail.com]
Verzonden: donderdag 9 juli 2009 14:40
Aan: Dennis Haarbrink
CC: internals@lists.php.net
Onderwerp: Re: [PHP-DEV] Type hinting - Request for DiscussionYou must learn what these quirks are. Likewise, every developer must
learn the quirks of the "type hinting" as they will almost certainly
be required to interact with code that uses it.In an extreme case, suppose that we completely balls-ed up the
semantics of type checks to be really really hard to use, but people
used them anyway. That would lead to a sharp learning curve. The
people who are against this proposal, or any other, know they will be
required to use it when it comes in, and have an interest in making
sure it is clean (whatever that means in each case). We shouldn't
dismiss their objections on the argument that they arent required to
use it. If its in the language, they are required to learn it.Paul
--
Paul Biggar
paul.biggar@gmail.com
Thanks for this elaboration, I totally see your point.
Regards,
Dennis Haarbrink
I'm a framework developer and I have great interest in type hinting/
casting.
I'm all for clarity and strictness, but it should definitely be a
choice.
PHP is known for its easy learning curve, that is one of its big
powers and
that should remain unchanged. But the way I see it is that it can be
implemented without requiring you to use it, if you want to use type
hinting/casting go ahead, if you don't want it, well, leave that bit
alone.
If it comes with a minor performance hit, OK, i can live with that,
I agree
with Lukas in that aspect, you don't spend lots of time checking/
casting
anyway.
As for hinting/casting would not be 'php-ish', i don't see it that
way, i
look at php as a language of possibilities, not restrictions.
I think you misunderstood Zeev. He wasn't saying that this feature is
not PHP-ish, he was specifically talking about "strict" type checking.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas,
-----Oorspronkelijk bericht-----
Van: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
Verzonden: donderdag 9 juli 2009 14:01
Aan: Dennis Haarbrink
CC: internals@lists.php.net
Onderwerp: Re: [PHP-DEV] Type hinting - Request for DiscussionI think you misunderstood Zeev. He wasn't saying that this feature is
not PHP-ish, he was specifically talking about "strict" type checking.regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Although I replied to Zeev's message it was more of a general observation
than directly aimed at him.
Regards,
Dennis
Zeev Suraski wrote:
We need to go back to the fundamentals - and look for use cases where
strict typing would be substantially superior to weak typing.
I whole-heartedly agree. I can see some benefits of having weak typing
(even though I'm not desperate for it) and think it would better fit PHP
than strict typing.
If someone brings up real world use cases for strict typing then please
not only include the function being called but also the calling code as
in my experience that's where the type juggling will happen once you
have strict typing. And that's where weak typing could shine IMHO.
Regards,
- Chris
I think we can take Lukas's RFC and either change it or write
something
based on it for weak typing only. If people here find it useful
I'll go
ahead and do that.I believe people don't want this. I wrote a set of rules, Lukas wrote
the RFC, and neither got anything like the support that strict typing
got.
Actually, in terms of weak typing we are now at 4 supporters of the
general idea:
Paul B.,
Lukas,
Zeev,
Christian S.
Still a minority compared to the +1 votes for Ilia's strict typing
proposal. Though it could be argued that a fair number only voted for
the expansion of type hinting to scalar datatypes and did not really
look into the entire strict vs. weak hinting stuff.
regards
Lukas Kahwe Smith
mls@pooteeweet.org
Actually, in terms of weak typing we are now at 4 supporters of the general
idea:
Paul B.,
Better make that 3 supporters. After seeing how complicated it was to
explain the semantics of a "sensible middle", I think the patch that
Ilia currently has is close to ideal (the strict semantics are trivial
to understand, the weak ones are the same as whats already here).
Naturally, I might change my position upon seeing the new RFCs.
Paul
--
Paul Biggar
paul.biggar@gmail.com
I want to remind everyone that this discussion is inadvertently sabotaging
the work/schedule of maintenance 5.3.x point releases, which we actually
need, for the 5.3 branch get to a point where it's stable enough to be used
in production.
So, knowing this can go on forever, it's time to pick which you want first:
A) Stable 5.3 with namespaces, closures, late static binding, phar, SPL
additions and more (essential brand new functionality, feature complete,
only needs bug fixes).
B) Strict type casts/hints (shortcut for existing is_*() / cast
functionality).
Regards,
Stan Vassilev
Hi list.
In advance, sorry for muddying the waters even further.
Following the current discussion about typehints to primitives, I'm
wondering if anyone have ever suggested to include some sort of
user-land contract system, such as the one that exists in
plt-scheme[1]
Given the dynamic nature of php, I would suspect that it might be a
much better fit. Unlike the semi-static typecheck that typehints can
give, a contract system would be much more expressive and would add a
lot more value (in my opinion anyway).
I think part of the reason for the popularity of typehints is that it
looks familiar for people coming from Java/C++/C#. The biggest
challenge for such a contract system would then be to come up with
something that doesn't look too alien. A simple way that I can think
of is to overload the meaning of typehints so that they may either
denote a class/interface (as they work currently) OR they may be a
function which takes the variable as argument and yields a boolean.
Eg.:
function array_of_numeric($x) {
foreach ($x as $val) {
if (!is_numeric($val)) {
return false;
}
}
return true;
}
class Foo {
/** Example use-case for a contract */
function sum(array_of_numeric $a) {
return array_sum($a);
}
}
This is just one suggestion - There are other ways to implement the concept.
I can see a number of benefits to a contract system over the currently
discussed typehint system:
- It covers all the use cases for a type-based system (You can use
is_integeras a contract, if you want that) - It's extensible in user-space, which means that it can be used to
convey much more accurate information, relevant to the application
needs. - It's focused on the interface of input-parameters, rather than their type.
[1] http://docs.plt-scheme.org/guide/contracts.html
--
troels
troels knak-nielsen wrote:
- It covers all the use cases for a type-based system (You can use
is_integeras a contract, if you want that)- It's extensible in user-space, which means that it can be used to
convey much more accurate information, relevant to the application
needs.- It's focused on the interface of input-parameters, rather than their type.
This is my favorite alternative so far. There are just a few problems
with parsing as I see it.
- How do you know if it is a contract or the current object type hint?
- It doesn't allow a type to be forced (casted) to the correct type.
To address these items, I suggest the following changes.
Change the syntax of the contract to look like a function call (which is
essentially what we are doing):
<?php
function array_of_numeric($x)
{
if (!is_array($x)) {
return false;
}
foreach ($x as $val) {
if (!is_numeric($val)) {
return false;
}
}
return true;
}
function sum(array_of_numeric($a)) {
return array_sum($a);
}
This could even be extended to allow for more generic types by allowing
constant parameters for the contract:
<?php
function array_of($x, $type)
{
if (!is_array($x)) {
return false;
}
switch ($type) {
case 'int':
$check = 'is_int';
break;
case 'float':
$check = 'is_float';
break;
case 'numeric':
$check = 'is_numeric';
break;
case 'string':
$check = 'is_string';
break;
case 'bool':
$check = 'is_bool';
break;
default:
return false;
}
foreach ($x as $val) {
if (!$check($val)) {
return false;
}
}
return true;
}
function sum(array_of($a, 'numeric')) {
return array_sum($a);
}
To allow for casting, the contract function could take the value by
reference and cast it:
<?php
function array_of_float(&$x)
{
if (!is_array($x)) {
return false;
}
foreach ($x as $key => $val) {
if (!is_numeric($val)) {
return false;
}
$x[$key] = (float)$val;
}
return true;
}
function sum(array_of_float($a)) {
return array_sum($a);
}
--
Joshua Thompson
Mechanical Engineer/Software Developer
http://www.schmalls.com
On Fri, Jul 10, 2009 at 2:28 AM, Josh
Thompsonspam.goes.in.here@gmail.com wrote:
troels knak-nielsen wrote:
- How do you know if it is a contract or the current object type hint?
The simplest solution would be to make one take precedence. You're not
likely to have both a class and a function with the same name, and if
you do, you kind of had it coming to you. For backwards compatibility
it would probably be most fitting to let the current behaviour
(class/interface) take precedence, although the other way around makes
for some quite interesting possibilities.
- It doesn't allow a type to be forced (casted) to the correct type.
As far as I can tell, this is a moot point. The whole discussion about
casting comes from the fact that hinting to a primitive type is more
restrictive than php's weak typing system. With a contract system this
problem doesn't exist. You could test that something conforms to your
specifications and then simply let the type system do its thing.
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
function addFive(is_numeric $x) {
return $x + 5;
}
Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.
--
troels
troels knak-nielsen wrote:
- How do you know if it is a contract or the current object type hint?
The simplest solution would be to make one take precedence. You're not
likely to have both a class and a function with the same name, and if
you do, you kind of had it coming to you. For backwards compatibility
it would probably be most fitting to let the current behaviour
(class/interface) take precedence, although the other way around makes
for some quite interesting possibilities.
I would much rather be explicit with a different syntax, that way we
don't have to add a new set of resolution rules. For example what would
this do to autoload? Would we have to call it to see if the class is
available every time? I think the function syntax disambiguates things
and hints at what is happening.
- It doesn't allow a type to be forced (casted) to the correct type.
As far as I can tell, this is a moot point. The whole discussion about
casting comes from the fact that hinting to a primitive type is more
restrictive than php's weak typing system. With a contract system this
problem doesn't exist. You could test that something conforms to your
specifications and then simply let the type system do its thing.
I can concede on this point. I just thought there might be some reason
you would need it in a specific type, but none are coming to mind...
--
Joshua Thompson
Mechanical Engineer/Software Developer
http://www.schmalls.com
All:
I'm in favor of this so-called "Weak" typing Zeev has proposed as
well, but I would like to see it become available in PHP before PHP 6.
That doesn't mean it has to go into 5.3.x, but I don't see why there
can't be a 5.4 that includes it. Personally, I think primitive typing
has a much more immediate need than many of the features proposed for
6 and, considering there is already been numerous working patches that
implement this feature in principal, I don't see why we can't have a
5.4 release including it. Waiting for PHP 6 is too long and the many
serious time-consuming tasks that are required to achieve the goals of
PHP 6 shouldn't stop a very useful feature like this from getting into
the wild promptly.
Secondly, I'd like to discuss a little something I thought about
regarding when PHP will/will not throw an error dealing with primitive
types. Specifically when dealing with user input (which always comes
across as a string to start), if you had something like...
function foo(int $a, int $b) { return $a + $b; }
and called:
foo($_GET['a'], $_GET['b']); // $_GET['a'] === "foo", $_GET['b'] === 5
According to Zeev's description of the behavior this would cause a
fatal error, as $_GET['a'] cannot be converted to an integer value.. I
like that, but I think we need to devise a mechanism that allows you
to catch this error at runtime and write application logic around
it... In the simple case above the point would be to be able to catch
the error so that the requesting user could be informed he must enter
two integer values. Off the top of my head the only mechanism that I
can think of would be to throw an exception, which I'm not crazy about
either:
try
{
print foo($_GET['a'], $_GET['b']);
} catch(TypeCheckException $e) {
print "Sorry, you need to provide two integer values!";
}
Personally I really like the practical feel and ease of understanding
of using an exception in this case, but the idea of an exception being
thrown from potentially procedural code isn't the best thing to me..
John
Hi!
According to Zeev's description of the behavior this would cause a
fatal error, as $_GET['a'] cannot be converted to an integer value.. I
like that, but I think we need to devise a mechanism that allows you
to catch this error at runtime and write application logic around
it... In the simple case above the point would be to be able to catch
Well, we could make it E_RECOVERABLE_ERROR. But it's not customizable,
unfortunately. If you want graceful handling (like custom error
messages), I don't believe you can do it language-level. Use app-level
validators (like Zend_Validate in Zend Framework) for that.
the error so that the requesting user could be informed he must enter
two integer values. Off the top of my head the only mechanism that I
can think of would be to throw an exception, which I'm not crazy about
either:try
{
print foo($_GET['a'], $_GET['b']);
} catch(TypeCheckException $e) {
print "Sorry, you need to provide two integer values!";
}
If you're going to write specific code to catch specific exceptions, why
don't you just check for specific constraints? It's the same amount of
code, but done the right way - you say what you actually mean to do and
do not make validation an afterthought, and allows you to give the user
much better feedback ("this field is wrong" instead of "some field is
wrong"). And what happens to your code after you add one more value? I
think app-level validation mechanism would work much better in this case.
Personally I really like the practical feel and ease of understanding
of using an exception in this case, but the idea of an exception being
thrown from potentially procedural code isn't the best thing to me..
I think exception would be impractical in real user-facing code - it's
too generic to give useful information, and you will have to have
validation on top of that anyway (emails, html, whatever).
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
[...]
For example, instead of:
function addFive(int $x) { return $x + 5; }You would simply do:
function addFive(is_numeric $x) { return $x + 5; }Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.
Please let me state that this is the greatest idea I read since the type hinting discussion began (and the only one I personally like, as I find all the other proposals really disappointing).
I'd like to see some real debating about this syntax proposed by troels:
function addFive(is_numeric($x)) {
...
}
Because I really like the idea of passing other parameters:
function check_multiple($a, $b) {
return !($a % $b);
}
function doSomething(check_multiple($a, 3)) {
// assume that $a is a multiple of 3
}
This solves all the problems I've understood so far:
-
BC breaks for new reserved keywords 'int', 'float', ...: there is no need for them anymore
-
weak typing vs strict typing:
function cast_bool(&$value) { $value = (bool) $value; return true; }
function weak_type_hinted(cast_bool($a)) { /* assume that $a is bool, no fatal errors */ } -
Nullable values:
function is_int_nullable($val) { return is_int($val) || is_null($val); }
function int_or_null(is_int_nullable($a)) { /* either $a is int or it's null */ } -
This will also make the error handling consistent where the classic type hinting wouldn't cover a particular use case:
function foo(int $a) { ... }
function bar($b) {
if ($b is not appropriated parameter)
trigger_error("Invalid parameter");
}
// a type of error (E_RECOVERABLE or TypeCheckException or whatever)
foo("inappropriate_parameter");
// a custom error, which might be slightly different from the one generated by the inner php engine
bar("another_inappropriate_parameter");
I think this gives the perfect freedom to the developers and makes everyone happy. I know your concerns about third party libraries that you might have to deal with, but if you trigger one of those errors, then it means you are not respecting the APIs, which means there is a bug in your application.
--
Giovanni Giacobbi
[...]
For example, instead of:
function addFive(int $x) { return $x + 5; }You would simply do:
function addFive(is_numeric $x) { return $x + 5; }Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.
I like it too. Not only it solves the initial problem, but it also
allows userland extensions. For example,
the current patch does not provide checks for callables, but we already
have is_callable in the core.
--
Ionut G. Stan
I'm under construction | http://igstan.blogspot.com/
2009/7/10 Ionut G. Stan ionut.g.stan@gmail.com
[...]
For example, instead of:
function addFive(int $x) { return $x + 5; }You would simply do:
function addFive(is_numeric $x) { return $x + 5; }Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.I like it too. Not only it solves the initial problem, but it also allows
userland extensions. For example,
the current patch does not provide checks for callables, but we already
have is_callable in the core.
But isn't is_numeric still a valid class name? Would that mean that classes
could no longer be called is_*?
[...]
For example, instead of:
function addFive(int $x) { return $x + 5; }You would simply do:
function addFive(is_numeric $x) { return $x + 5; }Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.I like it too. Not only it solves the initial problem, but it also
allows userland extensions. For example,
the current patch does not provide checks for callables, but we already
have is_callable in the core.
Hmmm, but it makes simple cases more complicated and slower. But I do like the
idea of generalising it with a function to handle 'strange' cases.
So, we have 3 syntaxes:
- function Foo(int $x) {
$x is tested to be integer, if it isn't an error is raised - either by exception
or just a fatal error.
A problem with this is that it could yeild some surprising results, eg:
Foo(4/2); -- OK
Foo(4/3); -- FAIL since 4/3 yeilds a float
In this last case people would learn to:
Foo((int)(4/3));
- function Foo((int) $x) {
$x is cast to int, ie converted iff possible - otherwise an error is raised:
int -> int -- OK
float -> int -- OK if in the range for integer
string -> int -- OK iff it is 100% clean:
'10' - OK
'10.1' - OK as string -> float -> int
'10ten' - FAIL/ERROR
etc
What happens when someone tries to use this syntax where he is casting to an object ?
I suggest that this fails unless the object has a __cast method, in which case that is invoked:
function Foo((MyObject) $x) {
...
}
class MyObject {
function __cast($x) {
if( ..... )
return new Foo('abcd', $x);
....
}
...
}
- function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
2009/7/10 Alain Williams addw@phcomp.co.uk
[...]
For example, instead of:
function addFive(int $x) { return $x + 5; }You would simply do:
function addFive(is_numeric $x) { return $x + 5; }Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.I like it too. Not only it solves the initial problem, but it also
allows userland extensions. For example,
the current patch does not provide checks for callables, but we already
have is_callable in the core.Hmmm, but it makes simple cases more complicated and slower. But I do like
the
idea of generalising it with a function to handle 'strange' cases.So, we have 3 syntaxes:
function Foo(int $x) {$x is tested to be integer, if it isn't an error is raised - either by
exception
or just a fatal error.A problem with this is that it could yeild some surprising results, eg:
Foo(4/2); -- OK Foo(4/3); -- FAIL since 4/3 yeilds a floatIn this last case people would learn to:
Foo((int)(4/3));
function Foo((int) $x) {$x is cast to int, ie converted iff possible - otherwise an error is
raised:
int -> int -- OK
float -> int -- OK if in the range for integer
string -> int -- OK iff it is 100% clean:
'10' - OK
'10.1' - OK as string -> float -> int
'10ten' - FAIL/ERROR
etcWhat happens when someone tries to use this syntax where he is casting to
an object ?
I suggest that this fails unless the object has a __cast method, in which
case that is invoked:function Foo((MyObject) $x) { ... } class MyObject { function __cast($x) { if( ..... ) return new Foo('abcd', $x); .... } ... }
function Foo(is_int($x)) {Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer much more
useful than just calling the is_numeric method in the function body. Plus
there's no longer the advantage of optimisers knowing the data-type.
Lewis.
function Foo(is_int($x)) {Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer
much more
useful than just calling the is_numeric method in the function body.
Plus
there's no longer the advantage of optimisers knowing the data-type.
right .. lets not forget the original goal (though it hasnt been
perfectly defined)
the idea was to move common validation code out of the function body
to reduce code, increase readability and enable IDE's to be even
smarter.
moving the function body into the signature was not the plan, as it
will kill the above features for the sake of flexibility.
the point is not flexibility, its finding a sensible common
denominator for validation of input parameters and optimizing the
syntax for that case.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi!
right .. lets not forget the original goal (though it hasnt been
perfectly defined)
the idea was to move common validation code out of the function body to
reduce code, increase readability and enable IDE's to be even smarter.
I think while intent is good (avoiding repetitive code) the strict
implementation would do exactly the opposite of what should be done - it
would move the repeated validation from library code to client code.
WHich would negatively influence both readability (in case you do it
right) and code robustness (in case you forget to do the necessary checks).
the point is not flexibility, its finding a sensible common denominator
for validation of input parameters and optimizing the syntax for that case.
Why the point can't be flexibility?
And if we talk about common denominator, how many use cases must accept
1, but not '1' or '1.0'? How many use cases can accept float, but can't
accept integer? How many use cases need boolean but can't accept 0? How
many use cases need string, but should never accept object with working
toString() like SimpleXML element? I don't see many such cases now. Do you?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
right .. lets not forget the original goal (though it hasnt been
perfectly defined)
the idea was to move common validation code out of the function
body to
reduce code, increase readability and enable IDE's to be even
smarter.I think while intent is good (avoiding repetitive code) the strict
implementation would do exactly the opposite of what should be done
- it would move the repeated validation from library code to client
code. WHich would negatively influence both readability (in case you
do it right) and code robustness (in case you forget to do the
necessary checks).
+1 ... this is one of the key points i tried to make in my RFC.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Please let me state that this is the greatest idea I read since the type hinting discussion began (and the only one I personally like, as I find all the other proposals really disappointing).
+1.
This contract system seems to be the best by far.
I think we can take Lukas's RFC and either change it or write
something
based on it for weak typing only. If people here find it useful
I'll go
ahead and do that.I believe people don't want this. I wrote a set of rules, Lukas wrote
the RFC, and neither got anything like the support that strict typing
got.Actually, in terms of weak typing we are now at 4 supporters of the
general idea:
Paul B.,
Lukas,
Zeev,
Christian S.
As I said in the other thread, I'm in favour of weak typing (and
against strict typing).
-g
Le Thu, 09 Jul 2009 21:11:31 +0200, Geoffrey Sneddon a écrit :
I think we can take Lukas's RFC and either change it or write
something
based on it for weak typing only. If people here find it useful I'll
go
ahead and do that.I believe people don't want this. I wrote a set of rules, Lukas wrote
the RFC, and neither got anything like the support that strict typing
got.Actually, in terms of weak typing we are now at 4 supporters of the
general idea:
Paul B.,
Lukas,
Zeev,
Christian S.As I said in the other thread, I'm in favour of weak typing (and against
strict typing).-g
Hello all,
I don't understand why you focus on " Strict / Weak " question.
For me it's very simple, it's not obligatory use Type Hiting. Developpers
wants to write a weak code, they'll just have to not use Type Hiting and
developpers wants wrote a stric code they'll have to use it.
After, choosing use or not Type Hinting when writing a librairy /
framework, this is not a php.internal problem.
It's a developper, designer, marketing choice ! Use or not use Type
hiting can help to chose a user target. And if you want be just between
weak and strict, " numeric " and " scalar " type hiting seems to be a
very good middle point.
+1 for Strict type hiting. (weak type hiting very similar to no type
hiting).
Hello all,
I don't understand why you focus on " Strict / Weak " question.
It is really about:
- type checking and enforcement
or - type casting and generation of an error if the value cannot be converted cleanly
Both of these have a value in different situations ... I would like to see both.
The option of no checking/casting (as at present) should remain.
For me it's very simple, it's not obligatory use Type Hiting. Developpers
wants to write a weak code, they'll just have to not use Type Hiting and
developpers wants wrote a stric code they'll have to use it.After, choosing use or not Type Hinting when writing a librairy /
framework, this is not a php.internal problem.
It's a developper, designer, marketing choice ! Use or not use Type
hiting can help to chose a user target. And if you want be just between
weak and strict, " numeric " and " scalar " type hiting seems to be a
very good middle point.+1 for Strict type hiting. (weak type hiting very similar to no type
hiting).
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit :
Hello all,
I don't understand why you focus on " Strict / Weak " question.
It is really about:
- type checking and enforcement
or- type casting and generation of an error if the value cannot be
converted cleanly
Thank for your response !
I vote for throw an exception if data type won't match. Have one error
when you make a mistake is better than have a silently casting which can
transform your data in another form than what you want.
And Exception is better than an Error because this give one chance to
programmer for resolving the problem before program be halted.
Alban wrote:
I don't understand why you focus on " Strict / Weak " question.
For me it's very simple, it's not obligatory use Type Hiting. Developpers
wants to write a weak code, they'll just have to not use Type Hiting and
developpers wants wrote a stric code they'll have to use it.After, choosing use or not Type Hinting when writing a librairy /
framework, this is not a php.internal problem.
It's a developper, designer, marketing choice ! Use or not use Type
hiting can help to chose a user target. And if you want be just between
weak and strict, " numeric " and " scalar " type hiting seems to be a
very good middle point.+1 for Strict type hiting. (weak type hiting very similar to no type
hiting).
I was just going to send something like this. Big +1 to this comment.
Just add type hinting (strict) and type casting (weak). It is up to the
developer to use either or none.
Strict should be strict, if the user wants float, the user get's float.
That's the way class/array type hinting works now.. Use the type casting
option if they want int to float. Things such as "is_numeric" or just
"numeric" would be nice but could be added later if need be.
Weak does have some questions around it, no argument there. But IMO just
make it work simplistically for now and add additional features later.
Some things won't work at the beginning so just document that. Ex: an
object can't be casted to anything other than string at this point. And
cast an object to another object.. Couple features would be a nice
addition to support this, __cast() and __box() __unbox(), but I doubt it
will be added at the same time. Unless effort is put forward for
everything in a 5.4 release, or wait for 6.0 (way to far out though).
Error handling I'm not sure about though. Should it be a error or
exception, not sure. I'd say if possible, if a function an error would
work, if a class method throw an exception. Just don't know though.
As far as the discussion about "if it's added then everyone will have to
use the feature, no choice, it'll show up at some point". That is up to
the projects code guidelines. If you're that concerned then it's up to
the manager to enforce the no use of the feature. /End
Hi!
Actually, in terms of weak typing we are now at 4 supporters of the
general idea:
Count me in, then :)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
2009/7/9 Zeev Suraski zeev@zend.com:
Two other issues that we need to revisit:
- Agree on when it will be implemented - I think it's pretty clear it
should not go to 5.3.
What would be the impact including this feature (once it is
technically fine for everybody) in 5.3 code with #ifdef's so that
this feature is enabled only at ./configure time and disabled by
default.
We could then imagine to switch this configure parameter as enabled by
default in a future (major) release.
This way, every vanilla PHP installation wouldn't suffer of BC
problems while still providing the feature to a restricted set of
users.
--
Patrick Allaert
http://code.google.com/p/peclapm/ - Alternative PHP Monitor
2009/7/9 Zeev Suraski zeev@zend.com:
Two other issues that we need to revisit:
- Agree on when it will be implemented - I think it's pretty
clear it
should not go to 5.3.What would be the impact including this feature (once it is
technically fine for everybody) in 5.3 code with #ifdef's so that
this feature is enabled only at ./configure time and disabled by
default.We could then imagine to switch this configure parameter as enabled by
default in a future (major) release.This way, every vanilla PHP installation wouldn't suffer of BC
problems while still providing the feature to a restricted set of
users.
thats a no go, since this would lead to incompatible PHP code. we have
had various php.ini settings that have caused this and we do not want
to pile onto this.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi!
I am a userland developer, so please take my advice with caution. I am not
aware of the consequences of any of the implementations from an internals
point of view. However, since the main question here seems to be strict
against weak typing, or casting, I feel I should voice my opinion.
From a user perspective, I feel that PHP does a very good job at casting
variables if needed. One should take care not to do anything stupid but
heh, that's programming... I therefore think using rules similar to the
casting rules is a good suggestion. It is easy to understand, easy to use
as a library developer and mostly, it is very easy to use for library users
(no change is needed to their code).
A function might look like this in PHP <= 5.3.0:
function foo ($x) {
return $x + 5; // hoping the user sends a numeric value, else the results
will be silently wrong
}
It could be used like this:
foo(5); // ok
foo('hello'); // wrong but no error
foo(fopen('hello')); // wrong but no error
foo(new CustomClass()); // wrong but no error
Or it could be written to check the type of the parameter:
function foo ($x) {
$y = (float) $x; // explicit cast
return $y + 5; // we know what type we have so we know the operation is
safe, we don't need any errors to be shown
}
The problem, as everyone is well aware, is that we need either to change the
value of $x (which I believe is bad practice) or to have a copy of $x cast
into $y, which of course means performance decrease and increased memory
consumption.
So, we all agree PHP should provide means to help developers simplify the
validation chain: type hinting (ie. telling the developer the parameters
should be converted before calling the function) or casting (ie. following
specific rules to cast to the right type).
With strong type hinting, the function would become:
function foo (float $x) { // if the user does not send a float value, the
function fails
echo $x + 5;
}
It could be used like this:
foo(5); // some kind of explicit error
foo((float) 5); // ok
foo(5.0); // ok
foo('hello'); // some kind of explicit error
foo((float) 'hello'); // wrong but that much is plain
foo(fopen('hello')); // some kind of explicit error
foo((float) fopen('hello')); // wrong but that much is plain
foo(new CustomClass()); // some kind of explicit error
foo((float) new CustomClass()); // wrong but that much is plain
We all agree, I hope, that this makes userland code very ugly, not to
mention very repetitive. Each time I call foo(), PHP would make me write a
manual cast on the parameters every time I call the function. I am quite
sure it helps to make the code a lot safer, but this is not at all what PHP
developers are used to do. And it would not help PHP's fame. To a user,
that would make PHP close to C or C++, but without the good performance. I
can see very little gain here.
Here is another example:
foo($var);
If I am not sure what type $var is at the time I call foo(), because this is
PHP and I have never had to worry about it before, strong type hinting would
have me do this:
foo((float) $var);
If I did that, my users would simply drop my libraries because they would
not appear to be written in PHP. Not the PHP they like, anyway. After all,
why would my libraries refuse an integer value when they expect a float?
And of course, PHP already has internal rules to convert several types to
others. Why not use that?
So, let's take a user point of view. As such, I defnitely would like to be
able to call my function foo() without any explicit casting every time I
need the function, under the threat that I would have errors when PHP should
already be able to cast the parameters.
foo(5); // ok
foo('hello'); // ok, empty
foo(fopen('hello')); // ok, could be empty or cast to: "0" for error, "1"
otherwise (like booleans in other languages)
foo(new CustomClass()); // ok, empty or maybe a handler can be set to
automatically cast in this case?
Of course, these are set values. Day to day programming does not always
involve hard-coded values like this but rather user-supplied values, ie.
mostly text values. I my experience, most of the time text values are easy
to cast to other types. I think this is why type hinting/casting could be
of great help.
Maybe a nice addition would be a specific error level so that I could see
where in my code these silent castings should take place. Or where they do
take place. Or neither.
foo($bar); // throws an error only if error_level is set to E_HINT
Bottom line: As a user of libraries, I see no good in strong hint typing.
However, as a library developer I see uses for it.
Best regards,
--
Guillaume Rossolini
hi,
I'm still in favour of #2 (Ilia's patch) as I don't see a real benefit
of a weak typing implementation, it defeats the main goal of this
addition. I'm also still opposed to add such thing in 5.3.x.
Cheers,
- Move forward with the semantics of the current patch. This approach has
substantial drawbacks in my opinion, and is a strong misfit with the rest of
PHP (again, in my opinion). See previous posts from Stas, Rasmus, myself
and maybe others illustrating this point. Lukas's 'Strict and Weak Typing
RFC' (http://wiki.php.net/rfc/typecheckingstrictandweak) has some good
insight as to why strict typing is problematic in PHP.
--
Pierre
At 10:42 10/07/2009, Pierre Joye wrote:
hi,
I'm still in favour of #2 (Ilia's patch) as I don't see a real benefit
of a weak typing implementation, it defeats the main goal of this
addition. I'm also still opposed to add such thing in 5.3.x.
Can you elaborate on what is the main goal of this addition that
using weak-typing implementation instead would defeat? (with
emphasis on use case(s) including both calling & called code,
otherwise we'd be back and forth on a matter of pure personal preference).
Zeev