[PHP-DEV] Re: [lists.php] Re: [PHP-DEV] PHP 6 : a new API ?
So why not avoiding this by adding it as methods of the scalar variable instead, aka autoboxing. This would allow the new api to be closer to what people are used to from other languages, needs far less typing and IDE autocomplete of available functions pr type with -. I would also prefer autoboxing, at least for arrays and strings (unsure about numbers). Would also be cool with some resources e.g. gd library. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 : a new API ?
On Feb 20, 2013, at 11:19 , Sebastian Krebs krebs@gmail.com wrote: 2013/2/20 Klaus Ufo klaus...@yahoo.fr Hi there ! We all know that the current PHP API has flaws. Maybe we could use namespaces to build a new coherent PHP API ? Like : - \arr - \num - \str and so on. Advantages : - no more global functions Just to throw that in: Even if you pack them into namespaces they will still remain global functions. They simply don't live in the root-namespace anymore. +1 So why not avoiding this by adding it as methods of the scalar variable instead, aka autoboxing. This would allow the new api to be closer to what people are used to from other languages, needs far less typing and IDE autocomplete of available functions pr type with -. More recent example by Nikita Popov, see unit tests of the project for examples: https://github.com/nikic/scalar_objects/blob/master/tests/string.phpt#L17 - separation of concerns - backward compatibility - work can be done progressively - easy to add user-defined functions (using php namespaces) - we could provide a \str\utf8 namespace This is just an idea. I don't know what is your vision for a next PHP 6. KH -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 : a new API ?
On 02/19/2013 11:22 PM, Klaus Ufo wrote: Hi there ! We all know that the current PHP API has flaws. Maybe we could use namespaces to build a new coherent PHP API ? Like : - \arr - \num - \str and so on. Advantages : - no more global functions - separation of concerns - backward compatibility - work can be done progressively - easy to add user-defined functions (using php namespaces) - we could provide a \str\utf8 namespace This is just an idea. I don't know what is your vision for a next PHP 6. KH I'm aware people complain about PHP flaws, but having misc global core functions for strings, arrays and other data types is a new one. I am still a purest at heart and don't see the need for namespacing in general. I am thinking it provides some lower level memory space improvements and less conflicts, but I feel like if you can't code in global space perhaps you should be rethinking how you code. I don't think most people care about the lower level advantages, they're just looking at it from a code laziness perspective. Why make \bar\baz\foo() or $bar-baz-foo() instead of bar_baz_foo()? Prefixing functions seems perfectly effective. I see a lot of code that looks like they're using namespaces or OO just to group things together and organize code in some fashion. Not because there's any inherent benefit. I'd much rather see effort taken on renaming functions to be more consistent, and making needle/haystack consistent, and maybe throw in named parameters. PHP is getting too complex as it is. Signed, PHP purest at heart, (who has code that has lasted for a decade and multiple major php code changes still did not break it) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 : a new API ?
Hello, On Wed, Feb 20, 2013 at 9:22 AM, Klaus Ufo klaus...@yahoo.fr wrote: Hi there ! We all know that the current PHP API has flaws. Maybe we could use namespaces to build a new coherent PHP API ? Like : - \arr - \num - \str and so on. Advantages : - no more global functions I actually like global functions even if most of the time I spend is in OO code. I don't want / need to have simple scripts / crons that are suddenly more complex to manage just because I can't have them. - separation of concerns While I understand the needs to be pure about things, I do think that there's such a thing as too pure. Does the current way of things break something? - backward compatibility This would rather be a backward incompatibility if I understand this correctly. - work can be done progressively - easy to add user-defined functions (using php namespaces) I have no troubles in having my defined functions up and running as they are now. The fact that they are always in the global scope makes things much simpler for me when I want to do simple things. - we could provide a \str\utf8 namespace Wasn't UTF8 a major pita and abandoned in favor of better things for the moment? This is just an idea. I don't know what is your vision for a next PHP 6. KH My vision for the PHP 6 is rather different that yours and if you want, you can read about it here: http://florinpatan.ro/2013/02/11/next-big-thing-in-php/ (sorry if I'm not allowed to share such links here). And as Michael Shadle said, I'd rather have things like consistent parameters order or named parameters or both rather that namespacing functions like this. Regards. Florin Patan https://github.com/dlsniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 : a new API ?
2013/2/20 Klaus Ufo klaus...@yahoo.fr Hi there ! We all know that the current PHP API has flaws. Maybe we could use namespaces to build a new coherent PHP API ? Like : - \arr - \num - \str and so on. Advantages : - no more global functions Just to throw that in: Even if you pack them into namespaces they will still remain global functions. They simply don't live in the root-namespace anymore. - separation of concerns - backward compatibility - work can be done progressively - easy to add user-defined functions (using php namespaces) - we could provide a \str\utf8 namespace This is just an idea. I don't know what is your vision for a next PHP 6. KH -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] PHP 6 : a new API ?
Michael Shadle wrote: I'm aware people complain about PHP flaws, but having misc global core functions for strings, arrays and other data types is a new one. I am still a purest at heart and don't see the need for namespacing in general. I am thinking it provides some lower level memory space improvements and less conflicts, but I feel like if you can't code in global space perhaps you should be rethinking how you code. I don't think most people care about the lower level advantages, they're just looking at it from a code laziness perspective. Why make \bar\baz\foo() or $bar-baz-foo() instead of bar_baz_foo()? Prefixing functions seems perfectly effective. I see a lot of code that looks like they're using namespaces or OO just to group things together and organize code in some fashion. Not because there's any inherent benefit. I'd much rather see effort taken on renaming functions to be more consistent, and making needle/haystack consistent, and maybe throw in named parameters. PHP is getting too complex as it is. I've been talking to people about this concept for 2-3 years and get mixed responses about it. Although my approach is slightly different : instead of just namespacing existing functions, I'd go the extra mile to resolve the inconsistencies that PHP has had to live with for so long. So for example : - str_replace would have an identical function called String_replace (or \String\replace if you really want to have the namespacing, which actually wouldn't be required and might even cause conflicts for certain code already using namespaces with certain names) - strpos -- String_position with a needle/haystack that's consistent with String_replace - etc. The old functions would remain, so old code still works as before. Deprecating those old functions could be something for 6.2 or so, with actual removal for 7.0, meaning it provides people a full major release to adapt, which is much more gentle than what Python did. Given that PHP 5 is now almost 9 years old, if future major PHP releases follow the same pace, that should be enough time to declare 10-year old PHP code EOL ;-) Additionally, a lot of code could be 'fixed' automatically, since the functions would be identical, perhaps only differing in the parameter order, which is not an issue for automatic changes either. In fact, the concept is not really new. DateTime is probably the best existing example of such an implementation. We had to live with date_add, date_create, date_diff and so on, but DateTime provides a clearer, more consistent approach, one that could be replicated for most of the other language features. Pros : - Clearer naming, obviously. - Consistency across the board, in names and parameters - Easier for non-PHP developers to switch to the language. Now many of them see the mess that function names in PHP is (underscored, not underscored, with prefix, without prefix, 'to' written as 'to', 'to' written as 2, etc.) and they instantly turn back Cons : - There will be a very small performance hit, since 1 of the 2 will always be an alias for the other, be it with possible changed parameter order - More typing - yes, the names will (usually) be longer. But that's what auto-complete is for... - We'll be stuck with 2 names for every function for an entire major release and the parameter order would be different for some of them. - Purists will say that we're breaking their language. PHP purest at heart, (who has code that has lasted for a decade and multiple major php code changes still did not break it) I agree that in most cases, that's a good thing. But it's also how we ended up with a thing called the Y2k problem : stuff running forever. Disclaimer : I've been developing with PHP since 1997, so I'm very fond of the language. If it ain't broke, don't fix it is true, but I think we can all admit that on consistency level PHP has been at least badly damaged from the start. So maybe we need to think about fixing at least some parts of it. Don't get me wrong, I know it's not as easy as switching a incandescent light bulb to a led light bulb, but the hardest job will be deciding on the names themselves. But if we can find a common ground there (yes, yes, I'm dreaming), we might finally get a trully consistent set of core functions in PHP. And although it might not be the most critical improvement PHP needs, it most certainly would be one we could publicly brag about. Just my 2 cents... Kind regards, Wim -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 : a new API ?
On Wed, Feb 20, 2013 at 3:23 PM, Wim Godden wim.god...@cu.be wrote: I agree that in most cases, that's a good thing. But it's also how we ended up with a thing called the Y2k problem : stuff running forever. Disclaimer : I've been developing with PHP since 1997, so I'm very fond of the language. If it ain't broke, don't fix it is true, but I think we can all admit that on consistency level PHP has been at least badly damaged from the start. So maybe we need to think about fixing at least some parts of it. I wouldn't compare the two... I'm not using deprecated stuff (although it might be someday :() mainly just saying while everyone has been extending PHP into Java-land, JSON-esque short arrays, lots more OO fun, namespaces, etc... I could still code anything out of the box with procedural PHP 5.2.x for the most part (with only a couple function and parameter additions added in 5.3/5.4) I've never had any APC issues - whereas OO code has had odd incompatibilities, and IMHO the obsession with OO has introduced more complexity into the language and everything related to it. Not the popular opinion I know, but that's what open source is all about, right? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 6 : a new API ?
Hi there ! We all know that the current PHP API has flaws. Maybe we could use namespaces to build a new coherent PHP API ? Like : - \arr - \num - \str and so on. Advantages : - no more global functions - separation of concerns - backward compatibility - work can be done progressively - easy to add user-defined functions (using php namespaces) - we could provide a \str\utf8 namespace This is just an idea. I don't know what is your vision for a next PHP 6. KH -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 : a new API ?
On 02/19/2013 11:22 PM, Klaus Ufo wrote: Hi there ! We all know that the current PHP API has flaws. Maybe we could use namespaces to build a new coherent PHP API ? Like : - \arr - \num - \str and so on. Advantages : - no more global functions - separation of concerns - backward compatibility - work can be done progressively - easy to add user-defined functions (using php namespaces) - we could provide a \str\utf8 namespace This is just an idea. I don't know what is your vision for a next PHP 6. KH While it's good to see people float ideas, what is needed is real commitment to write the code to implement them. Can you comment on what participation you envisage for yourself? At the moment your email sounds like a someone should do list (see point 4 of https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process). If this isn't the case, I look forward to seeing some prototypes from you or from anyone else willing to contribute to your ideas. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
