Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
Hi! > So function aliases, new open tag and deprecation are bad. What about > the String class? Design it, write it and we'll see how it works. It's not like the process should *start* with including it in PHP core. You can write String class all by yourself, put it on github and once virtually everybody is using it, we'd gladly discuss including it as a standard extension. -- 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] I think that "Function naming inconsistency" bug deservers more attention
Hi! > I agree all of that would suck, but would it suck less than the > alternatives for the most people involved? Definitely not. I don't think most people involved care if it's called htmlentities or html_entities. Those are things that you learn once and don't care about them anymore, and if you forget, it takes a second to open the manual or activate code completion in your IDE. Dragging people into a language fragmentation and world of pain that follows just for that definitely does not fit my definition of "suck less". I understand there are some vocal people all over reddit and such that jump on every mention of PHP and start complaining about how function naming sucks and PHP is useless because of that. I think however the history proves it is of rather little importance. If we could fix it without causing major disruption - yeah, why not. But the cost of the solution you propose is way too high. -- 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] I think that "Function naming inconsistency" bug deservers more attention
Thank you for the link http://philsturgeon.co.uk/blog/2013/01/php-6-pissing-in-the-wind I didn't know that... getters/setters were dumped to the garbage... http://japfan.pl/uploads/media/dacffbe3073882e86057d04266675637.JPG I will go get a drink... Is there any log of votes? Like reasons why "no" people said "no"? Sorry for off-topic. I think I will quit visiting "internals", this just dosen't make any sense. 2013/1/26 Florin Razvan Patan : > Hi, > > Everyone here forgets that there's a little certification > run by some guys named Zend that factor in some of > these things as well. > > That's the point of not having consistency? Checking > if some have better memory that others? > > Also, I suppose that everyone can afford to look up > things on the PHP manual when doing debugging on > some crashed remote service via CLI only access. > > Now, on a nicer tone. > > Consistency across function name/parameters would > help out both new people that learn the language as > well as leave out one point when compared to the other > languages. > > Sure, there's no point in changing things just for the > sake of it but I don't get it why this couldn't be a > viable option for PHP 6 for example, which is a major > release. > > It would definitely help out new users and get some > bonus points while doing so in order to close the mouth > of those arguing that PHP is so inconsistent in naming > things. > > Phil Sturgeon had a nice idea on his blog, > http://philsturgeon.co.uk/blog/2013/01/php-6-pissing-in-the-wind > which I think could very well apply to PHP and maybe > something like this could be done by someone with > less C/PHP internals knowledge that some other > features. If that's the case and all we need is someone > to do the changes, then I could level up my C > knowledge and help out if no one else is willing to do > it. > > I'd dislike for it to be rejected with reasons like: > - but it doesn't bring anything new; > - it doesn't help us with anything; > - it doesn't solve real problems; > - the current functions reflect the underlying functions > used. I've been a PHP user (developer) for a couple of > years now and I really don't care what's the parameter > order for the functions that PHP use to help me out > getting my job done; > - perfection ain't good. > > > Best regards. > > Florin Patan > https://github.com/dlsniper > > > > > On Sat, Jan 26, 2013 at 7:13 PM, Kalle Sommer Nielsen wrote: >> Hi >> >> 2013/1/25 Damian Tylczyński : >>> I've seen discussion on reddit >>> http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/ >> >> There is one really clean solution to this "problem" for the >> consistency Guys that tend to complain about PHP endlessly; write the >> aliases in PHP that can be included, which can be considered just like >> using one of the frameworks thats filled with functions, it can be >> written quite fast and you can even use auto_prepend_file to include >> it in all scripts. >> >> As said in countless mails above, there is no gain for breaking BC due >> to "perfection". >> >> -- >> regards, >> >> Kalle Sommer Nielsen >> ka...@php.net >> >> -- >> 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] I think that "Function naming inconsistency" bug deservers more attention
Hi, Everyone here forgets that there's a little certification run by some guys named Zend that factor in some of these things as well. That's the point of not having consistency? Checking if some have better memory that others? Also, I suppose that everyone can afford to look up things on the PHP manual when doing debugging on some crashed remote service via CLI only access. Now, on a nicer tone. Consistency across function name/parameters would help out both new people that learn the language as well as leave out one point when compared to the other languages. Sure, there's no point in changing things just for the sake of it but I don't get it why this couldn't be a viable option for PHP 6 for example, which is a major release. It would definitely help out new users and get some bonus points while doing so in order to close the mouth of those arguing that PHP is so inconsistent in naming things. Phil Sturgeon had a nice idea on his blog, http://philsturgeon.co.uk/blog/2013/01/php-6-pissing-in-the-wind which I think could very well apply to PHP and maybe something like this could be done by someone with less C/PHP internals knowledge that some other features. If that's the case and all we need is someone to do the changes, then I could level up my C knowledge and help out if no one else is willing to do it. I'd dislike for it to be rejected with reasons like: - but it doesn't bring anything new; - it doesn't help us with anything; - it doesn't solve real problems; - the current functions reflect the underlying functions used. I've been a PHP user (developer) for a couple of years now and I really don't care what's the parameter order for the functions that PHP use to help me out getting my job done; - perfection ain't good. Best regards. Florin Patan https://github.com/dlsniper On Sat, Jan 26, 2013 at 7:13 PM, Kalle Sommer Nielsen wrote: > Hi > > 2013/1/25 Damian Tylczyński : >> I've seen discussion on reddit >> http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/ > > There is one really clean solution to this "problem" for the > consistency Guys that tend to complain about PHP endlessly; write the > aliases in PHP that can be included, which can be considered just like > using one of the frameworks thats filled with functions, it can be > written quite fast and you can even use auto_prepend_file to include > it in all scripts. > > As said in countless mails above, there is no gain for breaking BC due > to "perfection". > > -- > regards, > > Kalle Sommer Nielsen > ka...@php.net > > -- > 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] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
Hello, I'm not sure if it could be considered as a feature but what about these RFCs: https://wiki.php.net/rfc/error-optimizations https://wiki.php.net/rfc/grisu3-strtod Some of them have been opened for some time now. Also, wouldn't a cleanup of the current RFC listed for PHP help out in the process? I'm not sure what's the process for this, but it should be done at some point imho. Best regards. Florin Patan https://github.com/dlsniper On Thu, Jan 24, 2013 at 11:39 PM, David Soria Parra wrote: > > Hi Internals, > > as you might have read in the 5.5.0alpha4 announcments, we are moving > forward with 5.5.0. We are already a bit late on the schedule and > we want to begin the beta cycle in 14 days and concentrate on QA > for the 5.5.0 release from now on. > > This includes a feature freeze. No new features should be comitted to > the repository once we tagged the first beta on Feb 7. All outstanding > features will have to wait for 5.6.0 in a year unless there is a > really good reason for an exception. > > Feature Freeze is on Feb 7, 2013. > > Regards, >Julien and David > > -- > 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] I think that "Function naming inconsistency" bug deservers more attention
Hi 2013/1/25 Damian Tylczyński : > I've seen discussion on reddit > http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/ There is one really clean solution to this "problem" for the consistency Guys that tend to complain about PHP endlessly; write the aliases in PHP that can be included, which can be considered just like using one of the frameworks thats filled with functions, it can be written quite fast and you can even use auto_prepend_file to include it in all scripts. As said in countless mails above, there is no gain for breaking BC due to "perfection". -- 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] I think that "Function naming inconsistency" bug deservers more attention
sorry, I thought it is sth like session_set_save_handler() ... Regards, Thomas On Sat, Jan 26, 2013 at 12:50 PM, Pierre Joye wrote: > hi, > > On Sat, Jan 26, 2013 at 12:37 PM, Thomas Bley wrote: >>> https://github.com/nikic/scalar_objects >> >> I think register_primitive_type_handler() is too exclusive: > > The point of this prototype is to define what is the best APIs we can > create to solve the "inconsistencies"/clean the current API. This > specific function is only a helper here, I do not see it being > implemented core. > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
hi, On Sat, Jan 26, 2013 at 12:37 PM, Thomas Bley wrote: >> https://github.com/nikic/scalar_objects > > I think register_primitive_type_handler() is too exclusive: The point of this prototype is to define what is the best APIs we can create to solve the "inconsistencies"/clean the current API. This specific function is only a helper here, I do not see it being implemented core. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
I think register_primitive_type_handler() is too exclusive: Hi Thomas, as @nikic noted in the description, it's just a proof of concept. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
> https://github.com/nikic/scalar_objects
I think register_primitive_type_handler() is too exclusive:
When I use 2 frameworks in the same code base, one might do
register_primitive_type_handler('string', 'A\StringHandler') and the
other might do register_primitive_type_handler('string',
'B\StringHandler') in the bootstrap.
The result will be only the second one is working. Also I see more
variations instead of a cleanup.
Working with an IDE, register_primitive_type_handler requires type
hints to use auto completion:
register_primitive_type_handler('string', 'StringHandler');
/* @var $str StringHandler */
$str = 'foobar';
echo $str->length();
vs.
$str = new StringHandler('foobar');
echo $str->length();
Regards,
Thomas
On Sat, Jan 26, 2013 at 11:45 AM, Pierre Joye wrote:
> hi,
>
> On Sat, Jan 26, 2013 at 10:18 AM, Thomas Bley wrote:
>> So function aliases, new open tag and deprecation are bad. What about
>> the String class?
>> I think there was some "Let's ... start exploring lighter and more
>> approachable ways to attack Unicode" on internals ...
>
> Unicode is a totally different topic. I would suggest to look at intl
> (ICU) extension for a start.
>
> Also about cleanup the APIs, take a look at this prototype:
>
> https://github.com/nikic/scalar_objects
>
> This is something that would be much cleaner and without BC problems.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
I really like the idea 2013/1/26 Pierre Joye : > hi, > > On Sat, Jan 26, 2013 at 10:18 AM, Thomas Bley wrote: >> So function aliases, new open tag and deprecation are bad. What about >> the String class? >> I think there was some "Let's ... start exploring lighter and more >> approachable ways to attack Unicode" on internals ... > > Unicode is a totally different topic. I would suggest to look at intl > (ICU) extension for a start. > > Also about cleanup the APIs, take a look at this prototype: > > https://github.com/nikic/scalar_objects > > This is something that would be much cleaner and without BC problems. > > Cheers, > -- > Pierre > > @pierrejoye > > -- > 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] I think that "Function naming inconsistency" bug deservers more attention
hi, On Sat, Jan 26, 2013 at 10:18 AM, Thomas Bley wrote: > So function aliases, new open tag and deprecation are bad. What about > the String class? > I think there was some "Let's ... start exploring lighter and more > approachable ways to attack Unicode" on internals ... Unicode is a totally different topic. I would suggest to look at intl (ICU) extension for a start. Also about cleanup the APIs, take a look at this prototype: https://github.com/nikic/scalar_objects This is something that would be much cleaner and without BC problems. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
hi Anthony, On Sat, Jan 26, 2013 at 9:26 AM, Anthony Ferrara wrote: > Pierre et al, > >> I would prefer to have it in pecl and merge once ready/cleaned up. >> Yes, same idea than with APC, except that it could be faster (for what >> I read, waiting to see the sources). Also we can review and do the >> changes more easily. > > > Well, I think the one issue with doing it in PECL first is that it prevents > some deeper engine integration that could benefit the implementation > significantly. > > With that said, I think it's a bit too tight to try to merge this in for the > 5.5 beta freeze. Given the current RFC process requires a minimum of 2 weeks > (1 of comments and 1 of voting), it feels tight. I'm not saying that I think > we should stick to the numbers hard in this particular case, but it's also > not a trivial patch, and I feel that rushing wouldn't be the best idea. > > So with that said, may I suggest that we add 1 more round of Alpha to the > 5.5 release cycle, with the specific intent of merging this in (assuming the > implementation goes well). So we'd be talking about adding approximately 2 > weeks to the cycle, but it would ease the time and implementation pressures > that could otherwise cause issues. I think this feature is worth pushing 5.5 > back slightly, but at the same time not delaying it indefinitely until this > gets in. So if in 4 weeks (the time until the beta, under this strategy) > this isn't ready, it wouldn't make 5.5. But at the same time it gives us > enough time to implement it, understand the implementation and make a > decision that's based on a concrete implementation than an "in-progress" > one. > > Thoughts? It sounds good to me. However I would still like to have it in pecl so we can improve for php 5.3/4 as well. Or we will have to duplicate the efforts between APC and optimizer for the next years. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
So function aliases, new open tag and deprecation are bad. What about the String class? I think there was some "Let's ... start exploring lighter and more approachable ways to attack Unicode" on internals ... Regards, Thomas On Sat, Jan 26, 2013 at 9:57 AM, Rasmus Lerdorf wrote: > Please stop with these. We can't keep explaining why function aliases, > 20 years is a bad idea. > > There is a reason that REFERER is still around in HTTP. It is obviously > not spelled correctly, but the pain of fixing it would far outweigh the > appeasement of the pedants out there. Does it make it harder to figure > out HTTP-related stuff? Not really, you won't necessarily know this term > even exists until you learn about it. Same goes for PHP functions. If > you understand where they come from you expect them to be named strlen, > strchr, strpos, etc. and if you don't understand their origin then you > simply learn them or let your IDE autocomplete them for you. > > And if you really think this is something a majority of people are > interested in, write up an RFC and put it to a vote. And when that fails > write yourself a userspace "consistency" library that names all the > functions the way you feel would make them consistent and put it out > there. or heck, if you are worried about performance of a userspace > wrapper, write an extension that does it. But please stop posting about > it on internals. There are a lot of real issues we should be spending > cycles on. > > -Rasmus > > -- > 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] I think that "Function naming inconsistency" bug deservers more attention
On Sat, Jan 26, 2013 at 3:57 AM, Rasmus Lerdorf wrote: > Please stop with these. We can't keep explaining why function aliases, > 20 years is a bad idea. > > There is a reason that REFERER is still around in HTTP. It is obviously > not spelled correctly, but the pain of fixing it would far outweigh the > appeasement of the pedants out there. Does it make it harder to figure > out HTTP-related stuff? Not really, you won't necessarily know this term > even exists until you learn about it. Same goes for PHP functions. If > you understand where they come from you expect them to be named strlen, > strchr, strpos, etc. and if you don't understand their origin then you > simply learn them or let your IDE autocomplete them for you. > > And if you really think this is something a majority of people are > interested in, write up an RFC and put it to a vote. And when that fails > write yourself a userspace "consistency" library that names all the > functions the way you feel would make them consistent and put it out > there. or heck, if you are worried about performance of a userspace > wrapper, write an extension that does it. But please stop posting about > it on internals. There are a lot of real issues we should be spending > cycles on. > I don't think this could have been phrased any better :) *tip of the hat* > > -Rasmus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
Please stop with these. We can't keep explaining why function aliases, http://www.php.net/unsub.php
Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
On Sat, Jan 26, 2013 at 9:26 AM, Anthony Ferrara wrote: > Pierre et al, > > I would prefer to have it in pecl and merge once ready/cleaned up. > > Yes, same idea than with APC, except that it could be faster (for what > > I read, waiting to see the sources). Also we can review and do the > > changes more easily. > > > Well, I think the one issue with doing it in PECL first is that it prevents > some deeper engine integration that could benefit the implementation > significantly. > > With that said, I think it's a bit too tight to try to merge this in for > the 5.5 beta freeze. Given the current RFC process requires a minimum of 2 > weeks (1 of comments and 1 of voting), it feels tight. I'm not saying that > I think we should stick to the numbers hard in this particular case, but > it's also not a trivial patch, and I feel that rushing wouldn't be the > best idea. > > So with that said, may I suggest that we add 1 more round of Alpha to the > 5.5 release cycle, with the specific intent of merging this in (assuming > the implementation goes well). So we'd be talking about adding > approximately 2 weeks to the cycle, but it would ease the time and > implementation pressures that could otherwise cause issues. I think this > feature is worth pushing 5.5 back slightly, but at the same time not > delaying it indefinitely until this gets in. So if in 4 weeks (the time > until the beta, under this strategy) this isn't ready, it wouldn't make > 5.5. But at the same time it gives us enough time to implement it, > understand the implementation and make a decision that's based on a > concrete implementation than an "in-progress" one. > > Thoughts? > I'm ok with that, that's safe and clean :) Julien.P
Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
Pierre et al, I would prefer to have it in pecl and merge once ready/cleaned up. > Yes, same idea than with APC, except that it could be faster (for what > I read, waiting to see the sources). Also we can review and do the > changes more easily. Well, I think the one issue with doing it in PECL first is that it prevents some deeper engine integration that could benefit the implementation significantly. With that said, I think it's a bit too tight to try to merge this in for the 5.5 beta freeze. Given the current RFC process requires a minimum of 2 weeks (1 of comments and 1 of voting), it feels tight. I'm not saying that I think we should stick to the numbers hard in this particular case, but it's also not a trivial patch, and I feel that rushing wouldn't be the best idea. So with that said, may I suggest that we add 1 more round of Alpha to the 5.5 release cycle, with the specific intent of merging this in (assuming the implementation goes well). So we'd be talking about adding approximately 2 weeks to the cycle, but it would ease the time and implementation pressures that could otherwise cause issues. I think this feature is worth pushing 5.5 back slightly, but at the same time not delaying it indefinitely until this gets in. So if in 4 weeks (the time until the beta, under this strategy) this isn't ready, it wouldn't make 5.5. But at the same time it gives us enough time to implement it, understand the implementation and make a decision that's based on a concrete implementation than an "in-progress" one. Thoughts? Anthony
