Re: [PHP-DEV] bug tracker planning
On Thu, Jul 9, 2009 at 04:50, Greg Beaverg...@chiaraquartet.net wrote: The disadvantages are obvious: everyone has to have an account and give their email address to report a bug. The advantages are also obvious: I *hate* when I am required to signup and do all sorts of weird validation crap before I can file bug reports. Things get even worse when projects hide the new bug report links for not-logged in users. I tend to drop out of the process midway and get to the conclusion apparently they don't want me to report bugs. Also, there is no reason to maintain user system for bugs. Just outsource the login to openid or a captcha questions (Are you a zombie? don't know/yes/no). -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Type hinting - Request for Discussion
All, I think that we should revisit the options on the table. I have a feeling that much like many people didn't realize they're voting to bring this into 5.3 - many weren't fully aware of the options on the table and their implications (to be clear - I'm sure some were, but I think many were not). The options as I see them: 1. Do nothing. I think the vote established that this is not what people want. 2. Move forward with the semantics of the current patch. This approach has substantial drawbacks in my opinion, and is a strong misfit with the rest of PHP (again, in my opinion). See previous posts from Stas, Rasmus, myself and maybe others illustrating this point. Lukas's 'Strict and Weak Typing RFC' (http://wiki.php.net/rfc/typecheckingstrictandweak) has some good insight as to why strict typing is problematic in PHP. 3. Implement 'weak' typing. What does that mean? Conversion rules will be very similar to those for internal functions, but slightly stricter (like I said, if we were to rewrite the conversion rules for internal functions today - we'd probably make them slightly stricter, too). For example, if you denote that an argument is supposed to be an integer, then a string that looks like an integer (e.g. 17) would be silently converted to an integer, however, a string that does not look like an integer (e.g. foo) will error out. We need to come up with a complete pass/fail table, but that would be the theme. Unlike option #2, this fits the rest of PHP quite well (except for minor inconsistencies with internal functions - but these are dwarfed in comparison to the inconsistencies of option #2). Two other issues that we need to revisit: 1. Agree on when it will be implemented - I think it's pretty clear it should not go to 5.3. 2. Make sure people understand *why* we're implementing it - performance is certainly *not* the reason. Before moving ahead with votes or committing the code, I suggest we focus on the pros cons of options #2 and #3. Since the inconsistencies introduced by option #2 are very substantial (between internal and userland functions, and also how values behave in PHP in general), I suggest we focus on use cases where option #2 would be truly needed and superior to option #3. In other words - what is the added value and is it worth the price? I think we can take Lukas's RFC and either change it or write something based on it for weak typing only. If people here find it useful I'll go ahead and do that. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Hi Zeev,
I've been keeping a very close eye, and have taken part in a good few
discussions, including putting my own idea on the table.
On Thu, Jul 9, 2009 at 8:47 AM, Zeev Suraskiz...@zend.com wrote:
The options as I see them:
1. Do nothing. I think the vote established that this is not what people
want.
Agreed.
2. Move forward with the semantics of the current patch. This approach has
substantial drawbacks in my opinion, and is a strong misfit with the rest of
PHP (again, in my opinion). See previous posts from Stas, Rasmus, myself
and maybe others illustrating this point. Lukas's 'Strict and Weak Typing
RFC' (http://wiki.php.net/rfc/typecheckingstrictandweak) has some good
insight as to why strict typing is problematic in PHP.
I believe nearly all opinions voiced have wanted the current patch.
Many more were in favour of strict typing only, but for the few
dissenters, like myself, Ilia included casting semantics using (int)
syntax.
There are I think maybe 5 or 6 people who have expressed opinions
against this. All others have been pro (I'm not counting the vote
here, I'm looking at discussions).
3. Implement 'weak' typing. What does that mean? Conversion rules will be
very similar to those for internal functions, but slightly stricter (like I
said, if we were to rewrite the conversion rules for internal functions
today - we'd probably make them slightly stricter, too). For example, if
you denote that an argument is supposed to be an integer, then a string that
looks like an integer (e.g. 17) would be silently converted to an integer,
however, a string that does not look like an integer (e.g. foo) will error
out. We need to come up with a complete pass/fail table, but that would be
the theme. Unlike option #2, this fits the rest of PHP quite well (except
for minor inconsistencies with internal functions - but these are dwarfed in
comparison to the inconsistencies of option #2).
This seems like a good idea, but others disagree. I wrote a set of
rules for this, which are very much how you describe them: slightly
stricter than casting, but weaker than strict typing. In the
discussion, there was very little support, and so I withdrew it.
Two other issues that we need to revisit:
1. Agree on when it will be implemented - I think it's pretty clear it
should not go to 5.3.
The last discussion certainly made this clear. It should be cleared up
whether people want this is 5.4 (if it happens). I think its
established that people want this in 6.
2. Make sure people understand *why* we're implementing it - performance is
certainly *not* the reason.
I believe there was only two misguided souls who believed this would
lead to better performance. Everyone else wanted it on its merits.
Before moving ahead with votes or committing the code, I suggest we focus on
the pros cons of options #2 and #3. Since the inconsistencies introduced
by option #2 are very substantial (between internal and userland functions,
and also how values behave in PHP in general), I suggest we focus on use
cases where option #2 would be truly needed and superior to option #3. In
other words - what is the added value and is it worth the price?
It doesnt sound like you are aware of the casting semantics that Ilia
added. They are largely consistent with the internal function
semantics.
function x (int x) { /* fail on non-int */ }
function x ((int) x) { /* cast parameter to an int */ } // just like
internals functions
Indeed this adds the ability to make your function work like an
internals function (useful perhaps for library interfaces).
I think we can take Lukas's RFC and either change it or write something
based on it for weak typing only. If people here find it useful I'll go
ahead and do that.
I believe people don't want this. I wrote a set of rules, Lukas wrote
the RFC, and neither got anything like the support that strict typing
got.
One large problem is that it introduced a new 3rd set of rules, and
this set is not intuitive but rather slightly subjective (reasonable
people might disagree on whether a bool should be weakly converted to
an int, for example). The strict type checks are at least simple, and
the current weak ones are what people are used to.
Obviously I'm not against discussion, but we just had this discussion.
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On 09.07.2009, at 02:28, troels knak-nielsen wrote: On Thu, Jul 9, 2009 at 2:15 AM, Markmark...@gmail.com wrote: I personally would be highly in favor of adding type hinting/casting BUT with the benifit that php actually becomes faster if you do things like that. Afterall you can use way more effective c code if you know what you expect right? As for the version to include type I sure hope that all the people in favour of this change aren't basing their opinion on some delusion that it would improve performance in any way. well .. this will have an effect on performance. for one the additional checks will probably add a small overhead for all users. the reduction in user land type check code should of course improve performance. that being said, none of the above will have a significant relevant affect on performance in real world applications (which usually spend most of their time talking to data stores and not type checking). regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
At 11:39 09/07/2009, Paul Biggar wrote:
I believe nearly all opinions voiced have wanted the current patch.
Many more were in favour of strict typing only, but for the few
dissenters, like myself, Ilia included casting semantics using (int)
syntax.
I think that many of the people who expressed
support for that patch did not fully realize its
implications - much in the same way they weren't
quite realizing they're actually voting for
inclusion in PHP 5.3. I believe that if we had a
'clean' Weak typing RFC as well as a Strict
typing RFC, each with its pros and cons - there
would be very different results.
There are I think maybe 5 or 6 people who have expressed opinions
against this. All others have been pro (I'm not counting the vote
here, I'm looking at discussions).
I think you're right, but I also think it had to
do with dynamics more than with actual content.
The two approaches were never compared
head-to-head, with the pros and cons - and more
importantly - with use cases on why strict typing
is necessary despite the fact it's fairly 'alien' to PHP.
2. Â Make sure people understand *why* we're
implementing it - performance is
certainly *not* the reason.
I believe there was only two misguided souls who believed this would
lead to better performance. Everyone else wanted it on its merits.
Maybe - but the only way to make sure is to make it a clear part of the RFC(s).
It doesnt sound like you are aware of the casting semantics that Ilia
added. They are largely consistent with the internal function
semantics.
function x (int x) { /* fail on non-int */ }
function x ((int) x) { /* cast parameter to an int */ } // just like
internals functions
I am - and I think I like this even less than
pure strict typing because of increased WTF factor.
I think strict typing is wrong for PHP, and this
cannot be fixed by also adding something
else. The way to 'fix' this is by not adding
strict typing, and adding only weak typing.
Indeed this adds the ability to make your function work like an
internals function (useful perhaps for library interfaces).
If improved with slightly more intrusive checks
(like the ones suggested in my email) - then it
can be useful in mostly all of the places where strict typing would be used.
I think we can take Lukas's RFC and either change it or write something
based on it for weak typing only. Â If people here find it useful I'll go
ahead and do that.
I believe people don't want this. I wrote a set of rules, Lukas wrote
the RFC, and neither got anything like the support that strict typing
got.
This could be for a variety of reasons - one of
them is that people truly thought this through
and truly prefer strict typing to weak
typing. But that is just one of the
options. Another is that the difference between
the two approaches, as well as the issues with
strict typing - aren't fully understood by the
audience - and I believe that this is actually the case.
One large problem is that it introduced a new 3rd set of rules, and
this set is not intuitive but rather slightly subjective (reasonable
people might disagree on whether a bool should be weakly converted to
an int, for example). The strict type checks are at least simple, and
the current weak ones are what people are used to.
I definitely don't think we should add two new
semantics. Ideally we shouldn't add any
entirely-new semantics, and what I'm proposing is
to actually reuse the existing semantics for
internal functions - with very minor
modifications. Kind of like Semantics and
Semantics', rather than Sematnics1, Semantics2, Semantics3.
Obviously I'm not against discussion, but we just had this discussion.
Given the implications of introducing something
like that (that can easily grow in the future to
other parts of PHP) - and my belief that the
discussion missed key ingredients, we should discuss it further.
We need to go back to the fundamentals - and look
for use cases where strict typing would be
substantially superior to weak typing. As far as
reflection, code readability, optimization and
security is concerned - I can't find any
superiority, but maybe I'm missing something. We
already have an RFC that details the
disadvantages of strict typing (Lukas's
RFC). Let's focus on the advantages and see if they're worth it?
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Thu, Jul 9, 2009 at 10:46 AM, Zeev Suraskiz...@zend.com wrote: I believe that if we had a 'clean' Weak typing RFC as well as a Strict typing RFC, each with its pros and cons - there would be very different results. The two approaches were never compared head-to-head, with the pros and cons Another is that the difference between the two approaches, as well as the issues with strict typing - aren't fully understood by the audience - and I believe that this is actually the case. the discussion missed key ingredients, we should discuss it further. I think you are right that the discussions weren't sufficiently clear, and this could be resolved by better RFCs. This is obviously how it should have been done in the first place (look at the success of Python's PEPs). I'm not sure this will change things, and worry it might derail what we have now, but those are not good reasons to stop the discussion. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting - Request for Discussion
-Oorspronkelijk bericht-
Van: Zeev Suraski [mailto:z...@zend.com]
Verzonden: donderdag 9 juli 2009 11:46
Aan: Paul Biggar
CC: internals@lists.php.net
Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion
At 11:39 09/07/2009, Paul Biggar wrote:
I believe nearly all opinions voiced have wanted the current patch.
Many more were in favour of strict typing only, but for the few
dissenters, like myself, Ilia included casting semantics using (int)
syntax.
I think that many of the people who expressed
support for that patch did not fully realize its
implications - much in the same way they weren't
quite realizing they're actually voting for
inclusion in PHP 5.3. I believe that if we had a
'clean' Weak typing RFC as well as a Strict
typing RFC, each with its pros and cons - there
would be very different results.
There are I think maybe 5 or 6 people who have expressed opinions
against this. All others have been pro (I'm not counting the vote
here, I'm looking at discussions).
I think you're right, but I also think it had to
do with dynamics more than with actual content.
The two approaches were never compared
head-to-head, with the pros and cons - and more
importantly - with use cases on why strict typing
is necessary despite the fact it's fairly 'alien' to PHP.
2. Â Make sure people understand *why* we're
implementing it - performance is
certainly *not* the reason.
I believe there was only two misguided souls who believed this would
lead to better performance. Everyone else wanted it on its merits.
Maybe - but the only way to make sure is to make it a clear part of the
RFC(s).
It doesnt sound like you are aware of the casting semantics that Ilia
added. They are largely consistent with the internal function
semantics.
function x (int x) { /* fail on non-int */ }
function x ((int) x) { /* cast parameter to an int */ } // just like
internals functions
I am - and I think I like this even less than
pure strict typing because of increased WTF factor.
I think strict typing is wrong for PHP, and this
cannot be fixed by also adding something
else. The way to 'fix' this is by not adding
strict typing, and adding only weak typing.
Indeed this adds the ability to make your function work like an
internals function (useful perhaps for library interfaces).
If improved with slightly more intrusive checks
(like the ones suggested in my email) - then it
can be useful in mostly all of the places where strict typing would be
used.
I think we can take Lukas's RFC and either change it or write
something
based on it for weak typing only. Â If people here find it useful
I'll go
ahead and do that.
I believe people don't want this. I wrote a set of rules, Lukas wrote
the RFC, and neither got anything like the support that strict typing
got.
This could be for a variety of reasons - one of
them is that people truly thought this through
and truly prefer strict typing to weak
typing. But that is just one of the
options. Another is that the difference between
the two approaches, as well as the issues with
strict typing - aren't fully understood by the
audience - and I believe that this is actually the case.
One large problem is that it introduced a new 3rd set of rules, and
this set is not intuitive but rather slightly subjective (reasonable
people might disagree on whether a bool should be weakly converted to
an int, for example). The strict type checks are at least simple, and
the current weak ones are what people are used to.
I definitely don't think we should add two new
semantics. Ideally we shouldn't add any
entirely-new semantics, and what I'm proposing is
to actually reuse the existing semantics for
internal functions - with very minor
modifications. Kind of like Semantics and
Semantics', rather than Sematnics1, Semantics2, Semantics3.
Obviously I'm not against discussion, but we just had this discussion.
Given the implications of introducing something
like that (that can easily grow in the future to
other parts of PHP) - and my belief that the
discussion missed key ingredients, we should discuss it further.
We need to go back to the fundamentals - and look
for use cases where strict typing would be
substantially superior to weak typing. As far as
reflection, code readability, optimization and
security is concerned - I can't find any
superiority, but maybe I'm missing something. We
already have an RFC that details the
disadvantages of strict typing (Lukas's
RFC). Let's focus on the advantages and see if they're worth it?
Zeev
I am a long time (passive) list reader but seeing the direction of this
discussion makes me feel obligated to express my opinion.
I'm a framework developer and I have great interest in type hinting/casting.
I'm all for clarity and strictness, but it should definitely be a choice.
PHP is known for its easy learning curve, that is one
Re: [PHP-DEV] Type hinting/casting request for vote
On Wed, Jul 08, 2009 at 08:31:49PM +0200, Jordi Boggiano wrote: Since the votes seem to switch to 6.0 instead of 5.3, would it be feasible to throw an E_DEPRECATED in 5.3.1 if one declares a function/class called int/bool/object/whatever ? +1 We *must* think about the transition. Just throwing the idea in the wild since I am not able to assess if that's doable, but it might be a good idea to add it as soon as possible if it is, especially if we want to skip a 5.4 -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Hi Dennis, On Thu, Jul 9, 2009 at 11:49 AM, Dennis Haarbrinkden...@born05.nl wrote: The most important thing is that it is _optional_, you have the _choice_ to use it. Sorry to go a little bit off-topic, but this idea has been bandied around a lot over the last week, and I'd like to respond to it. Although the proposed checks are optional, nobody has a _choice_ to use a new language feature. Though you may choose not to use a feature in your code for whatever reason, it will appear in code from your colleagues, clients, or upstream libraries. Every feature in PHP will at some point be put in front of every PHP developer. As a result, the argument that you dont like it, so what, you have a choice not to use it, is simply incorrect. Though at some point the majority may have to overrule the views of the minority, please do not dismiss them out of hand with this logic. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
2009/7/9 Zeev Suraski z...@zend.com: Two other issues that we need to revisit: 1. Agree on when it will be implemented - I think it's pretty clear it should not go to 5.3. What would be the impact including this feature (once it is *technically* fine for everybody) in 5.3 code with #ifdef's so that this feature is enabled only at ./configure time and disabled by default. We could then imagine to switch this configure parameter as enabled by default in a future (major) release. This way, every vanilla PHP installation wouldn't suffer of BC problems while still providing the feature to a restricted set of users. -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 09.07.2009, at 13:10, Patrick ALLAERT wrote: 2009/7/9 Zeev Suraski z...@zend.com: Two other issues that we need to revisit: 1. Agree on when it will be implemented - I think it's pretty clear it should not go to 5.3. What would be the impact including this feature (once it is *technically* fine for everybody) in 5.3 code with #ifdef's so that this feature is enabled only at ./configure time and disabled by default. We could then imagine to switch this configure parameter as enabled by default in a future (major) release. This way, every vanilla PHP installation wouldn't suffer of BC problems while still providing the feature to a restricted set of users. thats a no go, since this would lead to incompatible PHP code. we have had various php.ini settings that have caused this and we do not want to pile onto this. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 09.07.2009, at 12:49, Dennis Haarbrink wrote: I'm a framework developer and I have great interest in type hinting/ casting. I'm all for clarity and strictness, but it should definitely be a choice. PHP is known for its easy learning curve, that is one of its big powers and that should remain unchanged. But the way I see it is that it can be implemented without *requiring* you to use it, if you want to use type hinting/casting go ahead, if you don't want it, well, leave that bit alone. If it comes with a minor performance hit, OK, i can live with that, I agree with Lukas in that aspect, you don't spend lots of time checking/ casting anyway. As for hinting/casting would not be 'php-ish', i don't see it that way, i look at php as a language of possibilities, not restrictions. I think you misunderstood Zeev. He wasn't saying that this feature is not PHP-ish, he was specifically talking about strict type checking. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Thu, Jul 9, 2009 at 1:33 PM, Dennis Haarbrinkden...@born05.nl wrote: I mean, libraries may have all kinds of quirks, you may not be satisfied with the supplied API or maybe even the entire philosophy behind it, but that shouldn't stop you from using it or is it? You must learn what these quirks are. Likewise, every developer must learn the quirks of the type hinting as they will almost certainly be required to interact with code that uses it. In an extreme case, suppose that we completely balls-ed up the semantics of type checks to be really really hard to use, but people used them anyway. That would lead to a sharp learning curve. The people who are against this proposal, or any other, know they will be required to use it when it comes in, and have an interest in making sure it is clean (whatever that means in each case). We shouldn't dismiss their objections on the argument that they arent required to use it. If its in the language, they are required to learn it. Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting - Request for Discussion
Hi Paul, -Oorspronkelijk bericht- Van: Paul Biggar [mailto:paul.big...@gmail.com] Verzonden: donderdag 9 juli 2009 13:03 Aan: Dennis Haarbrink CC: internals@lists.php.net Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion Although the proposed checks are optional, nobody has a _choice_ to use a new language feature. Though you may choose not to use a feature in your code for whatever reason, it will appear in code from your colleagues, clients, or upstream libraries. Every feature in PHP will at some point be put in front of every PHP developer. I don't think this is a really valid argument. I mean, libraries may have all kinds of quirks, you may not be satisfied with the supplied API or maybe even the entire philosophy behind it, but that shouldn't stop you from using it or is it? Regards, Dennis Haarbrink -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Zeev Suraski wrote: We need to go back to the fundamentals - and look for use cases where strict typing would be substantially superior to weak typing. I whole-heartedly agree. I can see some benefits of having weak typing (even though I'm not desperate for it) and think it would better fit PHP than strict typing. If someone brings up real world use cases for strict typing then please not only include the function being called but also the calling code as in my experience that's where the type juggling will happen once you have strict typing. And that's where weak typing could shine IMHO. Regards, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting - Request for Discussion
Lukas, -Oorspronkelijk bericht- Van: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] Verzonden: donderdag 9 juli 2009 14:01 Aan: Dennis Haarbrink CC: internals@lists.php.net Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion I think you misunderstood Zeev. He wasn't saying that this feature is not PHP-ish, he was specifically talking about strict type checking. regards, Lukas Kahwe Smith m...@pooteeweet.org Although I replied to Zeev's message it was more of a general observation than directly aimed at him. Regards, Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting - Request for Discussion
-Oorspronkelijk bericht- Van: Paul Biggar [mailto:paul.big...@gmail.com] Verzonden: donderdag 9 juli 2009 14:40 Aan: Dennis Haarbrink CC: internals@lists.php.net Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion You must learn what these quirks are. Likewise, every developer must learn the quirks of the type hinting as they will almost certainly be required to interact with code that uses it. In an extreme case, suppose that we completely balls-ed up the semantics of type checks to be really really hard to use, but people used them anyway. That would lead to a sharp learning curve. The people who are against this proposal, or any other, know they will be required to use it when it comes in, and have an interest in making sure it is clean (whatever that means in each case). We shouldn't dismiss their objections on the argument that they arent required to use it. If its in the language, they are required to learn it. Paul -- Paul Biggar paul.big...@gmail.com Thanks for this elaboration, I totally see your point. Regards, Dennis Haarbrink -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug tracker planning
Hannes Magnusson wrote: On Thu, Jul 9, 2009 at 04:50, Greg Beaverg...@chiaraquartet.net wrote: The disadvantages are obvious: everyone has to have an account and give their email address to report a bug. The advantages are also obvious: I *hate* when I am required to signup and do all sorts of weird validation crap before I can file bug reports. Things get even worse when projects hide the new bug report links for not-logged in users. I tend to drop out of the process midway and get to the conclusion apparently they don't want me to report bugs. Also, there is no reason to maintain user system for bugs. Just outsource the login to openid or a captcha questions (Are you a zombie? don't know/yes/no). Hi, Actually, I hate requiring to do weird crap before filing too, and PEAR's system was designed for people who hate doing crap prior to filing. That's why the system PEAR uses is (1) file bug (2) verify email. Incidentally, I may have been unclear: the new bug report link is not hidden, just bugs from unverified users are not included in the public list of bugs (about 60-80% of new bugs are ads for manly drugs, so this is a good thing). signed in developers can see them and can also manually mark them as spam which causes them to be purged daily. The feeling of using it is infinitely friendlier than that used by trackers such as Bugzilla where clicking report bug goes to a blank page with a user/pass prompt. Greg P.S. the first time I sent this, the words manly drugs were a 6 letter word starting with v and the mail server rejected it with: 550 550 we're manly enough already (state 18). Nice :). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] technical issues in type hinting patch are not as big of an issue as it appears
Hi,
It is important to realize that the sole question here is what kind of
type hinting to implement. Any technical problems can be resolved with
some trade-offs.
There are a couple of approaches that come to mind.
1) make all type hints slightly slower (double lexing, once as T_STRING,
and then again)
use T_STRING for type hints, so that int/bool/etc. do not become new
reserved words, and do the lexing at parse-time. In addition, now that
we have namespaces, it is possible to definitively distinguish between a
true int type hint and an int class type hint:
function (\int $integerObject) {}
function (int $actualInteger) {}
This kind of double lexing is already performed to detect the parent
keyword in several places, as this is not a reserved word in PHP, so the
hit is not so bad.
The tradeoffs here are:
* double scanning of T_STRINGs in type hints at parse-time (no extra
performance hit beyond the run-time type verification for users of
opcode caches)
* potential confusion when suddenly methods with existing type hints
matching int and company start complaining about arguments not being
integers.
2) use cast syntax
function (int $integerObject) {}
function ((int) $actualInteger) {}
The tradeoff here is an intellectual one: (int) means something
different in a method signature than what it means in regular PHP code.
3) introduce a new syntax for scalar type hints
function (int! $actualInteger) {}
the drawback here is that it adds to the learning curve to learn what
int! means (and why it is so excited :)
All of these examples are just to say that there is no technical issue
that can't be solved with some kind of tradeoff, the main question is to
decide what kind of type hinting to implement, strict/casting/something
in between.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: rdohms
I would like to keep writing tests for PHP as I have started in the PHP Test Fest. During this event i lead my UG to write 144 tests (PHPSP) and I myself wrote 51 tests, for the below functions: Rafael Dohms : 51 (9 basic, 41 error, 1 variation) imagechar: 8 imagecharup: 8 imagecolordeallocate: 5 imagefontheight: 2 imagefontwidth: 2 imagegammacorrect: 6 imagelayereffect: 4 imagestring: 8 imagestringup: 8 I already have Karma in the Wiki with this username and i'm waiting for GSoC to be over to begin work on a DocFest which has already been discussed with phillip in #php.doc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 09.07.2009, at 10:39, Paul Biggar wrote: I think we can take Lukas's RFC and either change it or write something based on it for weak typing only. If people here find it useful I'll go ahead and do that. I believe people don't want this. I wrote a set of rules, Lukas wrote the RFC, and neither got anything like the support that strict typing got. Actually, in terms of weak typing we are now at 4 supporters of the general idea: Paul B., Lukas, Zeev, Christian S. Still a minority compared to the +1 votes for Ilia's strict typing proposal. Though it could be argued that a fair number only voted for the expansion of type hinting to scalar datatypes and did not really look into the entire strict vs. weak hinting stuff. regards Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Thu, Jul 9, 2009 at 5:20 PM, Lukas Kahwe Smithm...@pooteeweet.org wrote: Actually, in terms of weak typing we are now at 4 supporters of the general idea: Paul B., Better make that 3 supporters. After seeing how complicated it was to explain the semantics of a sensible middle, I think the patch that Ilia currently has is close to ideal (the strict semantics are trivial to understand, the weak ones are the same as whats already here). Naturally, I might change my position upon seeing the new RFCs. Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
I want to remind everyone that this discussion is inadvertently sabotaging the work/schedule of maintenance 5.3.x point releases, which we actually need, for the 5.3 branch get to a point where it's stable enough to be used in production. So, knowing this can go on forever, it's time to pick which you want first: A) Stable 5.3 with namespaces, closures, late static binding, phar, SPL additions and more (essential brand new functionality, feature complete, only needs bug fixes). B) Strict type casts/hints (shortcut for existing is_*() / cast functionality). Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] one RM to rule them all
Aloha, FYI: Since 5.3.0 is out and we are now in maintenance mode for this branch, there is not really a need for a release manager in the strict meaning of the title. In other words we can now go back to the traditional model of having a single RM that is mostly busy with technical decisions. As such I am stepping down to avoid the confusion that people keep thinking of me as someone who can actually review patches. I will of course continue to do my best to track todo items for the various branches. Go Johannes! :) regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Hi list.
In advance, sorry for muddying the waters even further.
Following the current discussion about typehints to primitives, I'm
wondering if anyone have ever suggested to include some sort of
user-land contract system, such as the one that exists in
plt-scheme[1]
Given the dynamic nature of php, I would suspect that it might be a
much better fit. Unlike the semi-static typecheck that typehints can
give, a contract system would be much more expressive and would add a
lot more value (in my opinion anyway).
I think part of the reason for the popularity of typehints is that it
looks familiar for people coming from Java/C++/C#. The biggest
challenge for such a contract system would then be to come up with
something that doesn't look too alien. A simple way that I can think
of is to overload the meaning of typehints so that they may either
denote a class/interface (as they work currently) OR they may be a
function which takes the variable as argument and yields a boolean.
Eg.:
function array_of_numeric($x) {
foreach ($x as $val) {
if (!is_numeric($val)) {
return false;
}
}
return true;
}
class Foo {
/** Example use-case for a contract */
function sum(array_of_numeric $a) {
return array_sum($a);
}
}
This is just one suggestion - There are other ways to implement the concept.
I can see a number of benefits to a contract system over the currently
discussed typehint system:
1) It covers all the use cases for a type-based system (You can use
`is_integer` as a contract, if you want that)
2) It's extensible in user-space, which means that it can be used to
convey much more accurate information, relevant to the application
needs.
3) It's focused on the interface of input-parameters, rather than their type.
[1] http://docs.plt-scheme.org/guide/contracts.html
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] technical issues in type hinting patch are not as big of an issue as it appears
Hi!
2) use cast syntax
function (int $integerObject) {}
function ((int) $actualInteger) {}
The tradeoff here is an intellectual one: (int) means something
different in a method signature than what it means in regular PHP code.
Actually, it means pretty much the same - conversion to int type.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] technical issues in type hinting patch are not as big of an issue as it appears
Stanislav Malyshev wrote:
Hi!
2) use cast syntax
function (int $integerObject) {}
function ((int) $actualInteger) {}
The tradeoff here is an intellectual one: (int) means something
different in a method signature than what it means in regular PHP code.
Actually, it means pretty much the same - conversion to int type.
Hi,
You assume that cast type hinting will be the implementation chosen. If
the type hinting is in fact validation the way object type hinting is
(strict type hinting), no conversion takes place, and the meaning is
different. I should have said if strict type hinting is implemented
in the drawback description to make that clear.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] technical issues in type hinting patch are not as big of an issue as it appears
Hi! You assume that cast type hinting will be the implementation chosen. If the type hinting is in fact validation the way object type hinting is (strict type hinting), no conversion takes place, and the meaning is different. I should have said if strict type hinting is implemented in the drawback description to make that clear. If there's only strict typing, there's no reason to make it's syntax to be resembling typecasts. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Hi! Actually, in terms of weak typing we are now at 4 supporters of the general idea: Count me in, then :) -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 9 Jul 2009, at 18:20, Lukas Kahwe Smith wrote: On 09.07.2009, at 10:39, Paul Biggar wrote: I think we can take Lukas's RFC and either change it or write something based on it for weak typing only. If people here find it useful I'll go ahead and do that. I believe people don't want this. I wrote a set of rules, Lukas wrote the RFC, and neither got anything like the support that strict typing got. Actually, in terms of weak typing we are now at 4 supporters of the general idea: Paul B., Lukas, Zeev, Christian S. As I said in the other thread, I'm in favour of weak typing (and against strict typing). -g -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug tracker planning
Hi I very much miss the ability to add my email address to the bugs that I am interested in. This used to allow to me to track its progress. I wasn't not sure, if that is what you meant within Subscriptions.. - sriram Philip Olson wrote: The bug system today works fine but improvements are being made. I've gone through the lists and details from past attempts and will list ideas here. Please do not vote, but if a particular item appears like a bad idea then please explain. Or, discuss additional (or modified) ideas that will be useful to the PHP project. The new system[1] is based off the pear.php.net bug system (via Jani), which long ago was a fork of our current (bugs.php.net). Because of this, some of these items are already available via the pear geeks. The plan is to have one bug tracker that includes PEAR+PECL+Core+GTK+Etc. It's also planning to go live after Stage #1 is completed, and also Jani and 2009 GSoC student Felipe Ribeiro are working on this project. Soonish a test system will be setup for all to break. Yes, this really is happening. Most people like the current system because it's simple, and I don't foresee this changing. First stage: - Cleanup code (in progress) - Attachments : For a diff, test, backtrace, screenshot, whatever. (done) - Package/Type separation : Packages (like extensions) and Bug Types (like feature requests) are separate (done) - Defined/Documented permissions : For example, so we all know if a random person can comment on a bogus bug - Preview button, instead of only submit (almost done) - Deal with bug id clashes from current PECL/PEAR/PHP bug trackers, and associated links - Importing - Testing Second stage: - Additional history : When a bug was opened/closed etc. Currently we don't log this except in emails - Reclassification : Discuss how we handle this, like should old/new lists both receive emails? - Consider different captcha (like reCaptcha) for anonymous users - Voting : Do we use or care about this? Improve? - nofeedback improvements : People assume this means closed, when it does not Third stage: - Subscriptions : Allow people to subscribe to RSS and/or receive emails per bug/package - Tagging : Allow people to optionally attach tags to bugs - IRC integration : Allow bot integration to an IRC channel, like a #php.bugs resurrection - Optional milestones (in pearweb today) - Integrate with VCS. Research this, KISS. Ex. A commit containing PHP Bug #42 automagically appends info to the bugs db - Befriend systems like http://bts-link.alioth.debian.org/ - OpenID support, see also http://wiki.php.net/ideas/phpnetauth - Username finder for the 'assigned' boxes, see also http://people.php.net/ And as always, additional volunteers are welcome. Regards, Philip [1] http://cvs.php.net/viewvc.cgi/pear/Bugtracker/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Hi!
I am a userland developer, so please take my advice with caution. I am not
aware of the consequences of any of the implementations from an internals
point of view. However, since the main question here seems to be strict
against weak typing, or casting, I feel I should voice my opinion.
From a user perspective, I feel that PHP does a very good job at casting
variables if needed. One should take care not to do anything stupid but
heh, that's programming... I therefore think using rules similar to the
casting rules is a good suggestion. It is easy to understand, easy to use
as a library developer and mostly, it is very easy to use for library users
(no change is needed to their code).
A function might look like this in PHP = 5.3.0:
function foo ($x) {
return $x + 5; // hoping the user sends a numeric value, else the results
will be silently wrong
}
It could be used like this:
foo(5); // ok
foo('hello'); // wrong but no error
foo(fopen('hello')); // wrong but no error
foo(new CustomClass()); // wrong but no error
Or it could be written to check the type of the parameter:
function foo ($x) {
$y = (float) $x; // explicit cast
return $y + 5; // we know what type we have so we know the operation is
safe, we don't need any errors to be shown
}
The problem, as everyone is well aware, is that we need either to change the
value of $x (which I believe is bad practice) or to have a copy of $x cast
into $y, which of course means performance decrease and increased memory
consumption.
So, we all agree PHP should provide means to help developers simplify the
validation chain: type hinting (ie. telling the developer the parameters
should be converted before calling the function) or casting (ie. following
specific rules to cast to the right type).
With strong type hinting, the function would become:
function foo (float $x) { // if the user does not send a float value, the
function fails
echo $x + 5;
}
It could be used like this:
foo(5); // some kind of explicit error
foo((float) 5); // ok
foo(5.0); // ok
foo('hello'); // some kind of explicit error
foo((float) 'hello'); // wrong but that much is plain
foo(fopen('hello')); // some kind of explicit error
foo((float) fopen('hello')); // wrong but that much is plain
foo(new CustomClass()); // some kind of explicit error
foo((float) new CustomClass()); // wrong but that much is plain
We all agree, I hope, that this makes userland code very ugly, not to
mention very repetitive. Each time I call foo(), PHP would make me write a
manual cast on the parameters every time I call the function. I am quite
sure it helps to make the code a lot safer, but this is not at all what PHP
developers are used to do. And it would *not* help PHP's fame. To a user,
that would make PHP close to C or C++, but without the good performance. I
can see very little gain here.
Here is another example:
foo($var);
If I am not sure what type $var is at the time I call foo(), because this is
PHP and I have never had to worry about it before, strong type hinting would
have me do this:
foo((float) $var);
If I did that, my users would simply drop my libraries because they would
not appear to be written in PHP. Not the PHP they like, anyway. After all,
why would my libraries refuse an integer value when they expect a float?
And of course, PHP already has internal rules to convert several types to
others. Why not use that?
So, let's take a user point of view. As such, I defnitely would like to be
able to call my function foo() without any explicit casting every time I
need the function, under the threat that I would have errors when PHP should
already be able to cast the parameters.
foo(5); // ok
foo('hello'); // ok, empty
foo(fopen('hello')); // ok, could be empty or cast to: 0 for error, 1
otherwise (like booleans in other languages)
foo(new CustomClass()); // ok, empty or maybe a handler can be set to
automatically cast in this case?
Of course, these are set values. Day to day programming does not always
involve hard-coded values like this but rather user-supplied values, ie.
mostly text values. I my experience, most of the time text values are easy
to cast to other types. I think this is why type hinting/casting could be
of great help.
Maybe a nice addition would be a specific error level so that I could see
where in my code these silent castings should take place. Or where they do
take place. Or neither.
foo($bar); // throws an error only if error_level is set to E_HINT
Bottom line: As a user of libraries, I see no good in strong hint typing.
However, as a library developer I see uses for it.
Best regards,
--
Guillaume Rossolini
Re: [PHP-DEV] Type hinting - Request for Discussion
troels knak-nielsen wrote:
1) It covers all the use cases for a type-based system (You can use
`is_integer` as a contract, if you want that)
2) It's extensible in user-space, which means that it can be used to
convey much more accurate information, relevant to the application
needs.
3) It's focused on the interface of input-parameters, rather than their type.
This is my favorite alternative so far. There are just a few problems
with parsing as I see it.
- How do you know if it is a contract or the current object type hint?
- It doesn't allow a type to be forced (casted) to the correct type.
To address these items, I suggest the following changes.
Change the syntax of the contract to look like a function call (which is
essentially what we are doing):
?php
function array_of_numeric($x)
{
if (!is_array($x)) {
return false;
}
foreach ($x as $val) {
if (!is_numeric($val)) {
return false;
}
}
return true;
}
function sum(array_of_numeric($a)) {
return array_sum($a);
}
This could even be extended to allow for more generic types by allowing
constant parameters for the contract:
?php
function array_of($x, $type)
{
if (!is_array($x)) {
return false;
}
switch ($type) {
case 'int':
$check = 'is_int';
break;
case 'float':
$check = 'is_float';
break;
case 'numeric':
$check = 'is_numeric';
break;
case 'string':
$check = 'is_string';
break;
case 'bool':
$check = 'is_bool';
break;
default:
return false;
}
foreach ($x as $val) {
if (!$check($val)) {
return false;
}
}
return true;
}
function sum(array_of($a, 'numeric')) {
return array_sum($a);
}
To allow for casting, the contract function could take the value by
reference and cast it:
?php
function array_of_float($x)
{
if (!is_array($x)) {
return false;
}
foreach ($x as $key = $val) {
if (!is_numeric($val)) {
return false;
}
$x[$key] = (float)$val;
}
return true;
}
function sum(array_of_float($a)) {
return array_sum($a);
}
--
Joshua Thompson
Mechanical Engineer/Software Developer
http://www.schmalls.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Fri, Jul 10, 2009 at 2:28 AM, Josh
Thompsonspam.goes.in.h...@gmail.com wrote:
troels knak-nielsen wrote:
- How do you know if it is a contract or the current object type hint?
The simplest solution would be to make one take precedence. You're not
likely to have both a class and a function with the same name, and if
you do, you kind of had it coming to you. For backwards compatibility
it would probably be most fitting to let the current behaviour
(class/interface) take precedence, although the other way around makes
for some quite interesting possibilities.
- It doesn't allow a type to be forced (casted) to the correct type.
As far as I can tell, this is a moot point. The whole discussion about
casting comes from the fact that hinting to a primitive type is more
restrictive than php's weak typing system. With a contract system this
problem doesn't exist. You could test that something conforms to your
specifications and then simply let the type system do its thing.
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
function addFive(is_numeric $x) {
return $x + 5;
}
Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
troels knak-nielsen wrote: - How do you know if it is a contract or the current object type hint? The simplest solution would be to make one take precedence. You're not likely to have both a class and a function with the same name, and if you do, you kind of had it coming to you. For backwards compatibility it would probably be most fitting to let the current behaviour (class/interface) take precedence, although the other way around makes for some quite interesting possibilities. I would much rather be explicit with a different syntax, that way we don't have to add a new set of resolution rules. For example what would this do to autoload? Would we have to call it to see if the class is available every time? I think the function syntax disambiguates things and hints at what is happening. - It doesn't allow a type to be forced (casted) to the correct type. As far as I can tell, this is a moot point. The whole discussion about casting comes from the fact that hinting to a primitive type is more restrictive than php's weak typing system. With a contract system this problem doesn't exist. You could test that something conforms to your specifications and then simply let the type system do its thing. I can concede on this point. I just thought there might be some reason you would need it in a specific type, but none are coming to mind... -- Joshua Thompson Mechanical Engineer/Software Developer http://www.schmalls.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
All:
I'm in favor of this so-called Weak typing Zeev has proposed as
well, but I would like to see it become available in PHP before PHP 6.
That doesn't mean it has to go into 5.3.x, but I don't see why there
can't be a 5.4 that includes it. Personally, I think primitive typing
has a much more immediate need than many of the features proposed for
6 and, considering there is already been numerous working patches that
implement this feature in principal, I don't see why we can't have a
5.4 release including it. Waiting for PHP 6 is too long and the many
serious time-consuming tasks that are required to achieve the goals of
PHP 6 shouldn't stop a very useful feature like this from getting into
the wild promptly.
Secondly, I'd like to discuss a little something I thought about
regarding when PHP will/will not throw an error dealing with primitive
types. Specifically when dealing with user input (which always comes
across as a string to start), if you had something like...
function foo(int $a, int $b) { return $a + $b; }
and called:
foo($_GET['a'], $_GET['b']); // $_GET['a'] === foo, $_GET['b'] === 5
According to Zeev's description of the behavior this would cause a
fatal error, as $_GET['a'] cannot be converted to an integer value.. I
like that, but I think we need to devise a mechanism that allows you
to catch this error at runtime and write application logic around
it... In the simple case above the point would be to be able to catch
the error so that the requesting user could be informed he must enter
two integer values. Off the top of my head the only mechanism that I
can think of would be to throw an exception, which I'm not crazy about
either:
try
{
print foo($_GET['a'], $_GET['b']);
} catch(TypeCheckException $e) {
print Sorry, you need to provide two integer values!;
}
Personally I really like the practical feel and ease of understanding
of using an exception in this case, but the idea of an exception being
thrown from potentially procedural code isn't the best thing to me..
John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
