Re: [PHP-DEV] one RM to rule them all
Hi Lukas, thanks a lot for your outstanding work! And maybe it attracts you organizing the release of PHP 7.0? Cheers, robert Am 09.07.2009 um 20:05 schrieb Lukas Kahwe Smith: 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
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
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
On Fri, Jul 10, 2009 at 2:28 AM, Josh Thompson 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: 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): This could even be extended to allow for more generic types by allowing constant parameters for the contract: To allow for casting, the contract function could take the value by reference and cast it: $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
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] 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! 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] 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] 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! 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] Type hinting - Request for Discussion
On 9 Jul 2009, at 18:20, Lukas Kahwe Smith wrote: On 09.07.2009, at 10:39, Paul Biggar wrote: I think we can take Lukas's RFC and either change it or write something based on it for weak typing only. If people here find it useful I'll go ahead and do that. I believe people don't want this. I wrote a set of rules, Lukas wrote the RFC, and neither got anything like the support that strict typing got. Actually, in terms of weak typing we are now at 4 supporters of the general idea: Paul B., Lukas, Zeev, Christian S. As I said in the other thread, I'm in favour of weak typing (and against strict typing). -g -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Hi 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
[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
I want to remind everyone that this discussion is inadvertently sabotaging the work/schedule of maintenance 5.3.x point releases, which we actually need, for the 5.3 branch get to a point where it's stable enough to be used in production. So, knowing this can go on forever, it's time to pick which you want first: A) Stable 5.3 with namespaces, closures, late static binding, phar, SPL additions and more (essential brand new functionality, feature complete, only needs bug fixes). B) Strict type casts/hints (shortcut for existing is_*() / cast functionality). Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Thu, Jul 9, 2009 at 5:20 PM, Lukas Kahwe Smith 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
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
[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
[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
Re: [PHP-DEV] bug tracker planning
Hannes Magnusson wrote: > On Thu, Jul 9, 2009 at 04:50, Greg Beaver 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
RE: [PHP-DEV] Type hinting - Request for Discussion
> -Oorspronkelijk bericht- > Van: Paul Biggar [mailto:paul.big...@gmail.com] > Verzonden: donderdag 9 juli 2009 14:40 > Aan: Dennis Haarbrink > CC: internals@lists.php.net > Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion > > You must learn what these quirks are. Likewise, every developer must > learn the quirks of the "type hinting" as they will almost certainly > be required to interact with code that uses it. > > In an extreme case, suppose that we completely balls-ed up the > semantics of type checks to be really really hard to use, but people > used them anyway. That would lead to a sharp learning curve. The > people who are against this proposal, or any other, know they will be > required to use it when it comes in, and have an interest in making > sure it is clean (whatever that means in each case). We shouldn't > dismiss their objections on the argument that they arent required to > use it. If its in the language, they are required to learn it. > > Paul > > > > -- > Paul Biggar > paul.big...@gmail.com Thanks for this elaboration, I totally see your point. Regards, Dennis Haarbrink -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting - Request for Discussion
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
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
On Thu, Jul 9, 2009 at 1:33 PM, Dennis Haarbrink 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
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 09.07.2009, at 13:10, Patrick ALLAERT wrote: 2009/7/9 Zeev Suraski : 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
2009/7/9 Zeev Suraski : > 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
Hi Dennis, On Thu, Jul 9, 2009 at 11:49 AM, Dennis Haarbrink 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/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 -- 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 intere
Re: [PHP-DEV] Type hinting - Request for Discussion
On Thu, Jul 9, 2009 at 10:46 AM, Zeev Suraski 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
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/casting request for vote
On 09.07.2009, at 02:28, troels knak-nielsen wrote: On Thu, Jul 9, 2009 at 2:15 AM, Mark 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
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 Suraski 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
[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] bug tracker planning
On Thu, Jul 9, 2009 at 04:50, Greg Beaver 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