Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
Sebastian Bergmann wrote: Can we bring the strings/hash table optimizations to PHP 5.3.x please? Performance optimizations, especially major ones like the ones you mention, should be treated the same as new features: they should not be introduced in a minor version. Give some of the things that have been added 'mid cycle' is there any real rule on that? As with PHP5.1 where we had to back pedal on some 'improvements' because of BC problems, 5.3.3 HAS to be installed if you want the current production namespace setup? But the real question is What needs to happen next to get features in HEAD available? I am sure a lot more people are interested in performance improvements and a lot of the esoteric stuff which is pervading the code base? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
2010/8/19 Sebastian Bergmann sebast...@php.net: Performance optimizations, especially major ones like the ones you mention, should be treated the same as new features: they should not be introduced in a minor version. + Most of such changes breaks ABI, which also is against our policies. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
With Traits, interned strings/hash table optimizations, array deref., Can we bring the strings/hash table optimizations to PHP 5.3.x please? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
Am 19.08.2010 01:32, schrieb steve: Can we bring the strings/hash table optimizations to PHP 5.3.x please? Performance optimizations, especially major ones like the ones you mention, should be treated the same as new features: they should not be introduced in a minor version. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Typehints (was Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)
On Tue Aug 10 07:42 PM, Josh Davis wrote: Derick's point was about consistency. The approach described in his mail is consistent with current syntax and mechanism(s). Current typehints do not apply any kind of conversion, so treating scalar hints the same way is consistent with the current mechanism. It's only consistent in the function declarations but *completely* inconsistent with how the rest of the language works. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Annoucing PHP 5.4 Alpha 1
Greetings hackers I spoke with Derick today, and we both agreed on releasing an alpha of PHP 5.4 to show the public what we have been working since 5.3. We are going to release an alpha at september 2nd, which meaning packaging is going to happen on 1st September (SVN tag, Windows binaries, etc.) With Traits, interned strings/hash table optimizations, array deref., type hinting, and more we both (me and Derick) belive we are ready for an alpha in September already. So I ask you geeks please make sure things are somewhat usable for the first public release of PHP 5.4 and post RFC's for inclusion in this alpha. If there is any questions regarding 5.4, then please email both me and Derick at our respective @php.net addresses and lets get this thing going ;-) I will spend out an email after the Alpha regarding a roadmap, with such things as PECL extensions in and out, possible RFC's, magic quotes and so forth. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote: type hinting For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
Total thumbs up on that. http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html just tells it all. A total epic fail. 2010/8/11 Johannes Schlüter johan...@schlueters.de: On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote: type hinting For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
2010/8/11 Johannes Schlüterjohan...@schlueters.de: On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote: type hinting For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. Is there a summary of what we ended up with? I got so tired of all the complaining on the the many threads I lost track. What are all the type hints we can use in a function definition in trunk? -- Brian. http://brian.moonspot.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Typehints (was Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)
On Wed, 11 Aug 2010, Johannes Schlüter wrote: On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote: type hinting For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. I will try to sum up my view point once more: 1. right now we *have* strict type checks for classes and arrays in the form of classname or array 2. the strict scalary type hint patch reuses this same syntax in the form of type-name to do the same thing in function arguments 3. we have casting type hints in the rest of the code in the form of (int). Some people don't like strict typehints, but the syntax as it currently is regarding type hints is *consistent*. Now, to allow both strict and casting hints, the logical step seems to be, to give the weak typehint advocates their tool as well: 4. We add casting typehings to function arguments in the form of (int) so that that is consistent as well. We would need to figure out whether we want: a. warnings on conversions (my choice) b. no warnings This: - keeps the syntax consistent - allows both strict and weak typehints Should make everybody happy (enough), right? regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
On 8/10/10 3:30 PM, Brian Moon wrote: 2010/8/11 Johannes Schlüterjohan...@schlueters.de: On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote: type hinting For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. Is there a summary of what we ended up with? I got so tired of all the complaining on the the many threads I lost track. What are all the type hints we can use in a function definition in trunk? They aren't hints. It is strict typing and in its current form I would ask you guys not to call the 5.4 release PHP. Because it won't be. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
Hi! With Traits, interned strings/hash table optimizations, array deref., type hinting, and more we both (me and Derick) belive we are ready for Please do not call strict typing type hinting. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
Hi! For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. I agree completely. The fact that obvious absence of consensus is ignored and we are releasing feature that clearly has no consensus behind it as a part of an official release - when we have killed much lesser things for much lesser reasons - I think it is a very bad development. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
On Aug 10, 2010, at 3:11 PM, Johannes Schlüter wrote: On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote: type hinting For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. johannes I'm happy to see a more strict implementation, but I think our numeric handling needs changed. We silently fall between them all in PHP. Sure we can guarantee array, null, bool, resource, string etc but not the numeric types. I think we should hold off on the Alpha until we're agreed with thats happening with that. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typehints (was Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)
Well, the thing is objects and arrays are complex types, so you can't
pass anything exept array to an array type hint, it just dosen't make
sence. Not everything can be converted to array and vice-versa. Same
with objects - every object is it's own type.
But the primitive types behave differently. It's because that they are
primitive, they easily convert from one to other back and fourth. I
don't see the need to be strict as really that feature will be used so
rearly, that it doesn't cost the effort. Really, any framework using
strict hints? How do you expect them to receive data from HTTP and
databases. It would require to write conversion rules for all data
they receive so it would be passed in the right type to the API. It's
just nuts.
The more realistic way is you define a function/method with the params
and wrap it into try {} catch {} block. If data is converted with the
data loss: for exmple you expect a numeric ID, but get a string of
chars - fetch the error and display an error message of a wrong ID.
Just the same way we do now - check for is_numeric and display the
error. This way the feature will be used. Strict types for dynamic
language is a non-sence.
Stop making things more complicated.
2010/8/11 Derick Rethans der...@php.net:
On Wed, 11 Aug 2010, Johannes Schlüter wrote:
On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
type hinting
For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.
I will try to sum up my view point once more:
1. right now we *have* strict type checks for classes and arrays in the
form of classname or array
2. the strict scalary type hint patch reuses this same syntax in the
form of type-name to do the same thing in function arguments
3. we have casting type hints in the rest of the code in the form of
(int).
Some people don't like strict typehints, but the syntax as it currently
is regarding type hints is *consistent*. Now, to allow both strict and
casting hints, the logical step seems to be, to give the weak typehint
advocates their tool as well:
4. We add casting typehings to function arguments in the form of (int)
so that that is consistent as well. We would need to figure out
whether we want:
a. warnings on conversions (my choice)
b. no warnings
This:
- keeps the syntax consistent
- allows both strict and weak typehints
Should make everybody happy (enough), right?
regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
They aren't hints. It is strict typing and in its current form I would ask you guys not to call the 5.4 release PHP. Because it won't be. Fully agreed. I'd suggest NoPHP. AntiPHP might also work. - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typehints (was Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)
Derick's point was about consistency. The approach described in his mail is consistent with current syntax and mechanism(s). Current typehints do not apply any kind of conversion, so treating scalar hints the same way is consistent with the current mechanism. Reusing the typecasting syntax for typecasting hints makes them more familiar to the users, and it is less ambiguous than a typehint that sometimes also typecasts. Plus, it allows for both strict typechecking and the more relaxed typecasting thing instead of forcing one. And all of that with a syntax that feels familiar. That, I believe, was his point. -JD -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typehints (was Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)
Hi! Derick's point was about consistency. The approach described in his mail is consistent with current syntax and mechanism(s). Current No it is not. There's no functions that produce errors when fed 1 instead of boolean true - all internal functions convert. typehints do not apply any kind of conversion, so treating scalar hints the same way is consistent with the current mechanism. Current hints do not apply conversion because conversion does not exist. There can be no conversion between different classes. Reusing the typecasting syntax for typecasting hints makes them more familiar to the users, and it is less ambiguous than a typehint that sometimes also typecasts. Plus, it allows for both strict That's exactly how internal functions worked in PHP for 10 years - sometimes (meaning when the type is wrong) typecast. That's how the rest of the language worked for 10 years in situations like $a = $b+1. How it's ambiguous - what are two options that you are confused between and can't choose? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typehints (was Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)
Yes, I understand the point of his post. But as you know - the perfect world and the real world rearly meat together. Just read the prevoius themes - majority was on the typecasting hints for the primitive types. We even layed the rules quite in detail. The thing is it will be pain in the ass to use strict typing just because the data comes in string representation from almost everywhere (PDO with mysqlnd makes a step to the right types from the database, but that's more an exception than a rule for now). I just don't think that there will be any sizeable codebase using the strict typing because one way or other the authors will just get fedup with converting data back and forth. Not to mention it just breaks the logic of the language. As Stas just wrote, people know from day one that if you feed 1 to a function expecting int, it will work just fine. In fact, the whole language and all internal functions work that way. The strict types will just break that pattern. Most of times when using some API I don't give a damn about what I get from the HTTP. I just do the blody $page = isset($_GET['page']) ? (int)$_GET['page'] : 0; to get an int. If user tries to do something by tampering with page params - he can do that as long as he want's. What that means, when strict typing is used, most of us will just do the blody conversion, because we don't wan't to get a fatal error, even if that's catchable. Converting hint will give us a warning, convert the value and off we go - log a warning, do the stuff so the user is happy. We see the error in the logs, check it, apply a fix and done with it. It's one thing if 12blabla makes into 12 int (sure I want to get a warning in the logs) or 1 becomes 1.0 for float (totally safe and sound). It would be good to see say 5 convert to true for bool - it's totally fine (again log an error/warning, this should be fixed). And it's totally different when we expect an array or an object of some type as a param. The handling of these structures just totally differes. To work with them you use different syntax, different aproaches. You can't substitute an array with something, same with objects. They should fit perfectly. It's not the reason to implement primitive type hinting like array and object type hints just because arrays and objects are done that way. Objects and arrays have a specific use syntax with special language constructs. If I expect an array - it should be an array or I will get a fatal error when trying to access an index for an int give, or try to access a method for the wrong object. But you can easilly expect a string and get an int instead, silently convert it to string and work as expected. Remember the main PHP principle? KISS. So keep it, blody hell, simple! Let the type hints to cast types when it's possible for primitive types! Personally I don't want to remember that there are two ways of defining a type hint and dig for bugs when others ment strict type hint, but wrote a typecasting one and forgot to make some checks before passing the argument relying on the hint. 2010/8/11 Josh Davis php...@gmail.com: Derick's point was about consistency. The approach described in his mail is consistent with current syntax and mechanism(s). Current typehints do not apply any kind of conversion, so treating scalar hints the same way is consistent with the current mechanism. Reusing the typecasting syntax for typecasting hints makes them more familiar to the users, and it is less ambiguous than a typehint that sometimes also typecasts. Plus, it allows for both strict typechecking and the more relaxed typecasting thing instead of forcing one. And all of that with a syntax that feels familiar. That, I believe, was his point. -JD -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typehints (was Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)
On 11 August 2010 01:50, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Derick's point was about consistency. The approach described in his mail is consistent with current syntax and mechanism(s). Current No it is not. There's no functions that produce errors when fed 1 instead of boolean true - all internal functions convert. First of all, I am talking about the typehinting syntax and mechanism here. As Derick pointed out, current typehints are strict. Secondly, I don't support amalgaming userland with internal functions. If I was to treat those internal functions as if they were written in userland, I'd say that they don't use scalar typehints, specifically for the reason you mentionned. Internal functions just typecast whatever you throw at them, no question asked. That's exactly how internal functions worked in PHP for 10 years - sometimes (meaning when the type is wrong) typecast. That's how the rest Again, I'm not talking about internal functions but typehinting. Now, when a userland developer uses typehints it means they expect a variable of a certain type to be passed. If they want typecasting, Derick proposes a convenient way to do that. How it's ambiguous The current typehinting system does not typecast. Changing that behaviour makes it ambiguous. It introduces a new behaviour grafted onto the old mechanism and without a new syntax. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typehints (was Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)
On 11 August 2010 02:13, Arvids Godjuks arvids.godj...@gmail.com wrote: Remember the main PHP principle? KISS. So keep it, blody hell, simple! Please try to realize that what you find simple may not appear as simple to everybody else. To me, typechecking is very simple: if type equals typehint then ok else error. Very simple. Describing the rules used when juggling types takes several pages of the PHP manual and some conversions are undefined. And from what I understand, the proposed typecasting typehints use slightly different rules. I'm sure you understand how one could see that as not simple. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
Sascha, Does this mean @group authorizes use of NoPHP as a name for a derivative PHP version (gotta ask according to the license) ? ;-) On Tue, Aug 10, 2010 at 7:04 PM, Sascha Schumann sas...@schumann.net wrote: They aren't hints. It is strict typing and in its current form I would ask you guys not to call the 5.4 release PHP. Because it won't be. Fully agreed. I'd suggest NoPHP. AntiPHP might also work. - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
