Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
Hello, you are right Damian. Also today on a german page: http://it-republik.de/php/news/Machen-wir-das-Namensschema-der-PHP-Funktionen-einheitlich%21-066539.html Relating to this bug report: https://bugs.php.net/bug.php?id=52424 Best regards Martin
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
hi, On Fri, Jan 25, 2013 at 3:37 PM, Martin Keckeis wrote: > Hello, > > you are right Damian. > > Also today on a german page: > http://it-republik.de/php/news/Machen-wir-das-Namensschema-der-PHP-Funktionen-einheitlich%21-066539.html > > Relating to this bug report: > https://bugs.php.net/bug.php?id=52424 We all know that, since years. The answer however remains the same: We can't do it without major backward compatibility breakages. Please check the internals archive for the past discussions. 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
2013/1/25 Pierre Joye > hi, > > On Fri, Jan 25, 2013 at 3:37 PM, Martin Keckeis > wrote: > > Hello, > > > > you are right Damian. > > > > Also today on a german page: > > > http://it-republik.de/php/news/Machen-wir-das-Namensschema-der-PHP-Funktionen-einheitlich%21-066539.html > > > > Relating to this bug report: > > https://bugs.php.net/bug.php?id=52424 > > We all know that, since years. The answer however remains the same: We > can't do it without major backward compatibility breakages. Please > check the internals archive for the past discussions. > Theoretically you can have both: The API in it's current state as well as a consistent api in the "php"-namespace. > > 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 > > -- github.com/KingCrunch
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
Hi! > I've seen discussion on reddit > http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/ > where many people are surprised why PHP can't have this done. Why > inconsistency is something that we want to keep because of backward > compatibility. PHP already introduced many backward compatibility I don't think you can just hand-wave the issue away by saying "PHP introduced BC breaks". First, PHP practically never introduced BC breaks that breaks almost all existing code. Even when we did huge changes - like OO model change - we had compatibility mode for a long time, and that considering in most scenarios it still worked the same. BC breaks happened, but they mattered only in some specific scenarios and usually this was done because old way of doing it could no longer be practically used or lead to bigger problems than BC (such as security issues or frequent hard-to-find bugs). Second, here we have breakage that would happen just for the sake of satisfying some people that thing having or not having underscore in function name really matters. For 99% of people out there, it does not. I agree it'd be nice if we came back in time and wrote function naming standard before PHP functions were implemented. But since we can't go back in time, we have to choose between things that matter to most of people - e.g., compatibility and code that keeps working when upgrading to next PHP version - against naming beauty that doesn't matter for most of them. I agree that beautiful is better than ugly. But, ugly but working is better than beautiful but broken. > names were created by some crazy "let's imagine some name and don't > look at API we have" man? Why we can't have PHP 6 that will be not > some amazingly featured-packed version but version with API that > just... makes sense. Because there would be zero incentive to upgrade to it for any current user. You'd have to rewrite and retest your code with zero benefit. And you'd have to maintain two codebases from now on for any application that is supposed to run on both, or resort to all kinds of trickery to keep it working. As someone working with 600K+ LOC code base, I don't see doing that as something I'm eagerly waiting for. Then the question is - why would we release a version that 99% of existing users would hate to use? -- 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
Well, how about renaming the functions, create aliases for BC and throw E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled with the distribution to migrate to the new convention? On Fri, Jan 25, 2013 at 1:41 PM, Stas Malyshev wrote: > Hi! > > > I've seen discussion on reddit > > > http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/ > > where many people are surprised why PHP can't have this done. Why > > inconsistency is something that we want to keep because of backward > > compatibility. PHP already introduced many backward compatibility > > I don't think you can just hand-wave the issue away by saying "PHP > introduced BC breaks". First, PHP practically never introduced BC breaks > that breaks almost all existing code. Even when we did huge changes - > like OO model change - we had compatibility mode for a long time, and > that considering in most scenarios it still worked the same. BC breaks > happened, but they mattered only in some specific scenarios and usually > this was done because old way of doing it could no longer be practically > used or lead to bigger problems than BC (such as security issues or > frequent hard-to-find bugs). > > Second, here we have breakage that would happen just for the sake of > satisfying some people that thing having or not having underscore in > function name really matters. For 99% of people out there, it does not. > I agree it'd be nice if we came back in time and wrote function naming > standard before PHP functions were implemented. But since we can't go > back in time, we have to choose between things that matter to most of > people - e.g., compatibility and code that keeps working when upgrading > to next PHP version - against naming beauty that doesn't matter for most > of them. I agree that beautiful is better than ugly. But, ugly but > working is better than beautiful but broken. > > > names were created by some crazy "let's imagine some name and don't > > look at API we have" man? Why we can't have PHP 6 that will be not > > some amazingly featured-packed version but version with API that > > just... makes sense. > > Because there would be zero incentive to upgrade to it for any current > user. You'd have to rewrite and retest your code with zero benefit. And > you'd have to maintain two codebases from now on for any application > that is supposed to run on both, or resort to all kinds of trickery to > keep it working. As someone working with 600K+ LOC code base, I don't > see doing that as something I'm eagerly waiting for. Then the question > is - why would we release a version that 99% of existing users would > hate to use? > -- > 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
On 01/25/2013 10:55 AM, Seva Lapsha wrote: > Well, how about renaming the functions, create aliases for BC and throw > E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled > with the distribution to migrate to the new convention? Throwing warnings on perfectly working code is really a bad idea. It annoys users, slows down their code, and doesn't add any value at all to them. It should also be noted that many of the function names that people don't think are consistent are actually quite consistent when you consider that PHP is just a thin wrapper on top of underlying libraries. Functions from libc like tempnam() and strlen() are perfectly fine. The fact that you can go to your Linux command line and type: "man tempnam" to get a good idea of what is happening behind the scenes of the PHP function of the same name is a good thing. -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
Yes, it's extremely useful, especially because most of the php developers are developing under Linux and most of them are coming from C and many other languages. Give ma a break... Second thing, we're afraid of throwing deprecated errors. Let's see the case. On production machines there are errors hidden from the users (display errors: none or just strict, notice, deprecated types hidden), experienced developers when they will not like them during development will disable them or migrate their code, new developers will just learn new API. Where is the problem? I'm not talking about removing some functions but just deprecating them to to get some time and simply to be ready to improve the PHP as a language in the future when time will come. 25 sty 2013 20:04, "Rasmus Lerdorf" napisał(a): > On 01/25/2013 10:55 AM, Seva Lapsha wrote: > > Well, how about renaming the functions, create aliases for BC and throw > > E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled > > with the distribution to migrate to the new convention? > > Throwing warnings on perfectly working code is really a bad idea. It > annoys users, slows down their code, and doesn't add any value at all to > them. > > It should also be noted that many of the function names that people > don't think are consistent are actually quite consistent when you > consider that PHP is just a thin wrapper on top of underlying libraries. > Functions from libc like tempnam() and strlen() are perfectly fine. The > fact that you can go to your Linux command line and type: "man tempnam" > to get a good idea of what is happening behind the scenes of the PHP > function of the same name is a good thing. > > -Rasmus > >
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
On Fri, Jan 25, 2013 at 2:04 PM, Rasmus Lerdorf wrote: > On 01/25/2013 10:55 AM, Seva Lapsha wrote: > > Well, how about renaming the functions, create aliases for BC and throw > > E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled > > with the distribution to migrate to the new convention? > > Throwing warnings on perfectly working code is really a bad idea. It could be a new type of notice then, which could be controlled by configuration. > It annoys users, The configuration could be turned off by default. > slows down their code, Isn't it a flaw of the current implementation of throwing messages, which could be improved? AFAIU, if suppressed warnings would not be processed as the active ones, the performance effect would be negligible to zero. > and doesn't add any value at all to them. > It would add the value to those who care. > It should also be noted that many of the function names that people > don't think are consistent are actually quite consistent when you > consider that PHP is just a thin wrapper on top of underlying libraries. > Functions from libc like tempnam() and strlen() are perfectly fine. The > fact that you can go to your Linux command line and type: "man tempnam" > to get a good idea of what is happening behind the scenes of the PHP > function of the same name is a good thing. > True. Don't get me wrong, I personally don't mind using the good old names, even typos in the names have their own charm. I just think that the point of view of order-freaks could be respected a little after all these years of complaints, so I'm trying to find a compromise and more PHP users would be happy. :) > > -Rasmus > >
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
Hi! > Well, how about renaming the functions, create aliases for BC and throw > E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled > with the distribution to migrate to the new convention? Well, the problem with these things is this: suppose you have testing suite that verifies your code. What you do with E_DEPRECATED? You can treat them as failure, and that means in hypothetical PHP 6 release you code is broken, and you can't release it until you fixed it - so that means for you the effect it as if the function was effectively removed. On the other hand, you can ignore it - and then when these functions are removed, you get all your code broken, and while it is not removed, it's like we didn't do anything. The purpose of deprecation is to give you time to upgrade your code, but the question here is - why would you want to change your perfectly working code, if there would be no benefit to you but couple of underscored placed here and there so people could feel better knowing every function has underscore in the same place? As I said, while it's nice, I don't think it is worth it. When the change is necessary - e.g., when we have API that is flawed or unsafe, take the recent example of CURL file uploading API, which exposes tricky security issues - then deprecation/removal may be warranted, because your code, that you think is working, might in fact have security hole. So we find that avoiding security hole is more important. But I personally do not see how adding underscores is as important. If somebody came forward and proposed better API - that could exist in parallel with current one, but eventually replace it if people like it so much nobody would use the old one anymore - it could be discussed. But just shuffling couple of underscores here and there - really, I don't see how it is worth the trouble. -- 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
On 1/25/2013 7:02 PM, Stas Malyshev wrote: Hi! Well, how about renaming the functions, create aliases for BC and throw E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled with the distribution to migrate to the new convention? Well, the problem with these things is this: suppose you have testing suite that verifies your code. What you do with E_DEPRECATED? You can treat them as failure, and that means in hypothetical PHP 6 release you code is broken, and you can't release it until you fixed it - so that means for you the effect it as if the function was effectively removed. On the other hand, you can ignore it - and then when these functions are removed, you get all your code broken, and while it is not removed, it's like we didn't do anything. Depending on just what is going to change, a simple script people can run to scan their code and spit out a diff of recommended changes they can simply review and approve of could be pretty painless. Then again you probably have people that would be subject to vendor updates without the ability to run the script or understand the changes it recommends. May be a small minority though. Are we talking mostly needle/haystack & haystack/needle type BC changes here or other more nefarious things? Realistically couldn't we just introduce a configuration parameter to keep "the inconsistent parameter order," perhaps along with a script to suggest the changes needed to bring some code up to speed? Would be a bit more in the core, for a time, but would allow people to transition when they wanted to, without all of the errors... -- -Clint -- 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! > Realistically couldn't we just introduce a configuration parameter to > keep "the inconsistent parameter order," perhaps along with a script to > suggest the changes needed to bring some code up to speed? People think that "introduce a configuration parameter" is a solution to almost any BC problem in the engine. It's not true, actually it's the opposite - now you have to maintain two code bases, one for one value of the parameter and one for another. Now imagine there's 10 such parameters, for different things in PHP, and you get 1024 options to test you application on. That's why we try to reduce behavior-modifying options to a minimum. Config options are for configuration, not for changing engine behavior in BC-breaking way. That's one of the reasons why magic_* were not a good idea and we had to get rid of them. And imagine integrating a library that is written with one set of engine options into application that expects another set of options. Now imagine application that uses a dozen of third-party libraries (in current open-source world, it's not too many at all), each of them expecting its own set of engine-modifying options. It would very quickly become a complete nightmare. So I think we should try to keep PHP behavior unified and avoid behavior-modifying switches as much as possible. -- 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
On 1/25/2013 8:43 PM, Stas Malyshev wrote: Hi! Realistically couldn't we just introduce a configuration parameter to keep "the inconsistent parameter order," perhaps along with a script to suggest the changes needed to bring some code up to speed? People think that "introduce a configuration parameter" is a solution to almost any BC problem in the engine. It's not true, actually it's the opposite - now you have to maintain two code bases, one for one value of the parameter and one for another. Now imagine there's 10 such parameters, for different things in PHP, and you get 1024 options to test you application on. That's why we try to reduce behavior-modifying options to a minimum. Config options are for configuration, not for changing engine behavior in BC-breaking way. That's one of the reasons why magic_* were not a good idea and we had to get rid of them. And imagine integrating a library that is written with one set of engine options into application that expects another set of options. Now imagine application that uses a dozen of third-party libraries (in current open-source world, it's not too many at all), each of them expecting its own set of engine-modifying options. It would very quickly become a complete nightmare. So I think we should try to keep PHP behavior unified and avoid behavior-modifying switches as much as possible. I agree all of that would suck, but would it suck less than the alternatives for the most people involved? -- -Clint -- 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
Here I am, ten years later, and the same issue is being rehashed just as it was when it was brought up ten years ago. Over those ten years, things have slowly gotten better, but the underlying issue remains the same. PHP is glue. PHP has not taken the path of re-naming everything to conform to a new "PHP standard", other than underscores, and attempts at function prefixes. Sure, we could start adding aliases like libc_strlen(), and maybe that's worth a thought, but its adding another layer of complexity, to achieve simplicity. On Fri, Jan 25, 2013 at 11:04 AM, Rasmus Lerdorf wrote: > On 01/25/2013 10:55 AM, Seva Lapsha wrote: > > Well, how about renaming the functions, create aliases for BC and throw > > E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled > > with the distribution to migrate to the new convention? > > Throwing warnings on perfectly working code is really a bad idea. It > annoys users, slows down their code, and doesn't add any value at all to > them. > > It should also be noted that many of the function names that people > don't think are consistent are actually quite consistent when you > consider that PHP is just a thin wrapper on top of underlying libraries. > Functions from libc like tempnam() and strlen() are perfectly fine. The > fact that you can go to your Linux command line and type: "man tempnam" > to get a good idea of what is happening behind the scenes of the PHP > function of the same name is a good thing. > > -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
Clint Priest wrote: So I think we should try to keep PHP behavior unified and avoid behavior-modifying switches as much as possible. I agree all of that would suck, but would it suck less than the alternatives for the most people involved? E_STRICT is bad enough and is one of the switches you would have to test everything against. But the main problem is that there is nothing in the historic code base that easily allows someone to identify which version of PHP IS required to run it? THIS is where move code forward to comply with the existing 'E_DEPRECATED/E_STRICT' is a minefield, so adding yet another major rework seems to be a step too far? Now if someone could come up with a third party tool that reads an application ... identifies all of the problems ... and at least offer pointers to fix them ... -- 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 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- 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
> Now if someone could come up with a third party tool that reads an > application ... identifies all of the problems ... and at least offer > pointers to fix them ... I like that idea! Kinda surprised something like that doesn't already exist, actually --Kris
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
1) What about using a new open tag?
pos("lo")) {...
echo $s->htmlSpecialChars();
echo $s->convert("ISO-8859-1");
$a = new Array([1,2,3]);
if ($a->contains(1)) {...
Regards,
Thomas
On Sat, Jan 26, 2013 at 3:43 AM, Stas Malyshev wrote:
> Hi!
>
>> Realistically couldn't we just introduce a configuration parameter to
>> keep "the inconsistent parameter order," perhaps along with a script to
>> suggest the changes needed to bring some code up to speed?
>
> People think that "introduce a configuration parameter" is a solution to
> almost any BC problem in the engine. It's not true, actually it's the
> opposite - now you have to maintain two code bases, one for one value of
> the parameter and one for another. Now imagine there's 10 such
> parameters, for different things in PHP, and you get 1024 options to
> test you application on. That's why we try to reduce behavior-modifying
> options to a minimum. Config options are for configuration, not for
> changing engine behavior in BC-breaking way. That's one of the reasons
> why magic_* were not a good idea and we had to get rid of them.
>
> And imagine integrating a library that is written with one set of engine
> options into application that expects another set of options. Now
> imagine application that uses a dozen of third-party libraries (in
> current open-source world, it's not too many at all), each of them
> expecting its own set of engine-modifying options. It would very quickly
> become a complete nightmare.
>
> So I think we should try to keep PHP behavior unified and avoid
> behavior-modifying switches as much as possible.
> --
> 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
>
--
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] 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
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
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
> 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 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
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
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 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
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
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! > 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
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
> 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.
In userland we can only do something like
$str = new String('my_string_class');
echo $str->length();
But that's useless.
It would be great if method calls on primitive types could be supported, like
in Nikic' proof of concept (https://github.com/nikic/scalar_objects).
$str = 'my_string_class';
echo $str->length();
I would really like to see that in PHP. It's not only a nicer and shorter way
to code but it would also be a solution for the function naming inconsistency
;-)
Best regards
Christian
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Saturday, January 26, 2013 7:39 PM
To: Thomas Bley
Cc: internals@lists.php.net; Rasmus Lerdorf
Subject: 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
On 1/28/2013 2:09 AM, Christian Stoller wrote:
In userland we can only do something like
$str = new String('my_string_class');
echo $str->length();
But that's useless.
It would be great if method calls on primitive types could be supported, like
in Nikic' proof of concept (https://github.com/nikic/scalar_objects).
$str = 'my_string_class';
echo $str->length();
I would really like to see that in PHP. It's not only a nicer and shorter way
to code but it would also be a solution for the function naming inconsistency
;-)
+1 from that, fortunately since it's an extension it won't be subject to
a vote, you can use it or not. :) The core seems to be heavily
protected by the core developers.
Best regards
Christian
--
-Clint
--
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
> +1 from that, fortunately since it's an extension it won't be subject to a
> vote, you can use it or not. :) The core seems to be heavily protected by
> the core developers.
As an APC user, I would be also fine with an extension :-)
@pierre Would it be possible to get windows builds from nikita's repo?
Regards,
Thomas
On Mon, Jan 28, 2013 at 1:06 PM, Clint Priest wrote:
>
> On 1/28/2013 2:09 AM, Christian Stoller wrote:
>>
>> In userland we can only do something like
>> $str = new String('my_string_class');
>> echo $str->length();
>>
>> But that's useless.
>> It would be great if method calls on primitive types could be supported,
>> like in Nikic' proof of concept (https://github.com/nikic/scalar_objects).
>>
>> $str = 'my_string_class';
>> echo $str->length();
>>
>> I would really like to see that in PHP. It's not only a nicer and shorter
>> way to code but it would also be a solution for the function naming
>> inconsistency ;-)
>
>
> +1 from that, fortunately since it's an extension it won't be subject to a
> vote, you can use it or not. :) The core seems to be heavily protected by
> the core developers.
>
>> Best regards
>> Christian
>>
> --
> -Clint
>
>
> --
> 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
