Re: [PHP-DEV] Mailing list moderation
"Stanislav Malyshev" wrote in message news:cc1f4670-d201-5a06-7309-a2386f819...@gmail.com... Hi! You may not like what I have to say, but that is no reason to ban me from saying it. I believe in democracy and free speech, and by banning or suspending me you are effectively banning the right to free speech. This has nothing to do with free speech. You are welcome to exercise your rights to free speech any way you like. But you don't have the rights to be in the list if the community does not want it and if your behavior is unhelpful and un-conductive to the discussion. I can understand you banning or suspending someone because of personal abuse or offensive/foul language, but banning someone simply because you don't like what they say is a step too far. If this is allowed to happen then soon you will get to stage where someone says "Anyone who disagrees with my point of view is an idiot and should be banned from this list". In that case, you'd have to exercise your rights to free speech somewhere else. I am sure the world of democracy will survive this. This, of course, is not specific to anybody personally - anybody who does not think they can abide by the rules of civilized discussion Define "civilised". Anything which does not use foul or abusive language should be regarded as civilised. Expressing an unpopular opinion is still civilised. Anyone who tries to ban unpopular opinions should not be welcome on any list as this prevents proper discussion. on the list could exercise their free speech rights in other venues, of which there's always an abundance. Polite, substantial, productive discussion is welcome - we do not have any barriers or prerequisites for participation. Noise is not welcome. There are too many delicate people on this list who regard any opinion which differs from theirs as "noise". Nobody wants to see the noise on the list, and nobody wants to see yet more noise by discussing who started it and who kicked or spat first and who broke whose sand castle. I suggest you start by aiming your wrath at those who move off-topic and start making personal attacks instead of those who defend themselves from such attacks. Everybody must behave, or take a time out and relax and think about more pleasant matters until they are able to be polite again. Again, not about anybody personally, applies to all. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Mailing list moderation
"Thomas Punt" wrote in message news:am4pr0901mb1265e675e7965065989892e5f9...@am4pr0901mb1265.eurprd09.prod.outlook.com... Hi! Hi, This mail is going to both the systems group and internals mailing list. I would like to request a mailing list suspension for the users tonymars...@hotmail.com and li...@rhsoft.net, who have recently been aggressively derailing the "Scalar Pseudo-type" thread, despite requests to moderate their participation both in that thread, and on a number of previous instances -- this is certainly not the first time these two users have converted an RFC discussion into a dick measuring contest. +1 They've generated so much unnecessary noise on this mailing list that I've had to set up rules in Outlook to automatically mark their emails as read in order to skip past them. Let's keep discussions on the mailing list on topic and fruitful. -Tom You may not like what I have to say, but that is no reason to ban me from saying it. I believe in democracy and free speech, and by banning or suspending me you are effectively banning the right to free speech. As a long time user of PHP I earn a living by selling my software all over the world, so I have a vested interested in seeing that the language is not changed in a detrimental way. I have seen too many RFCs which do not provide genuine benefits for the greater PHP community, instead they pander to the personal whims of a vociferous minority who want to change the language to suit their personal coding style, or to fit their idea of purity. As for all this so-called "dick measuring" if you bothered to read the posts you should see that I try to keep my comments as civil as possible, but when some prat attacks me personally on this list then I have the right to defend myself. You should focus your attention of those who make personal attacks and not those who are defending themselves. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
"Lester Caine" wrote in message news:a1bb2452-3969-ca72-cf19-4ca4bcd90...@lsces.co.uk... On 31/12/17 22:45, Michael Morris wrote: Please do not quote large swaths of Tony Marston's crap. He's an unrepentant liar, braggart and trouble maker that most of the list has on ignore since the admins can't be bothered to do their job and kick him. Just because you don't like what I write does not give you reason to call it crap. You call me an unrepentant liar - can you point to anything that I have said that has proven to be a lie? You call me a braggart - but at least I have a code base that is still going strong after 15 years without using any of those optional extras that have been added to the language starting with PHP 5. You call me a trouble maker - what trouble have I made and for whom? You should learn to keep your insults to yourself. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
wrote in message news:96908b43-e2b3-923a-5452-903f26838...@rhsoft.net... Am 01.01.2018 um 10:21 schrieb Tony Marston: Any attempt to make typehinting (or type enforcement as it has now become) is simply adding complications to the language which do not provide benefits to the greater PHP community, just a minority of poor coders who want the language to trap the bugs that they create in their code. There are some of us out there who are capable of writing bug-free code without type enforcement, so this RFC (and anything else connected with type hinting/enforcement) is something we don't need to use, therefore it has no benefits for us. breaking news: nobody is enforces anything to you just don't use features you don't want to use but fix your dirty attitude that everything you don't need should be voted down! I never said that just because I personally won't use a proposed feature that it should be voted down. It should only be voted up if it can provide benefits to the greater PHP community and not just a few individuals. I specifically said that if you don't understand an RFC or the benefits that it is supposed to provide then you should vote it down, otherwise you could be held responsible for allowing the language to be corrupted. "There are some of us out there who are capable of writing bug-free code" is a laughable argumentation anyways Why is that laughable? You appear to want to make the language more complicated just to catch the bugs that you keep creating. Some of us have learned how not to write such buggy code in the first place. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
"Dustin Wheeler" wrote in message news:a93010e9-7e52-4144-81b8-6fb6f47d8...@ncsu.edu... On Dec 31, 2017, at 10:33 AM, "li...@rhsoft.net" <li...@rhsoft.net> wrote: Am 31.12.2017 um 11:27 schrieb Tony Marston: "Michael Morris" wrote in message news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dnbswf9csuyntyn8x...@mail.gmail.com... On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <les...@lsces.co.uk> wrote: Not being able to vote, many of us have no option to complain about the way things are going. Currently there seems to be several styles of PHP form the nice and simple untyped version I moved to from very strictly typed hard compiled code I'd been using up until then, through to current code which is reliant on third party things like PSR and Composer and expects only strictly typed PHP. This is born of the fact that while ignoring datatype makes learning PHP easier, it makes using it harder - especially when testing. I strongly disagree. I have been using PHP since 2001 and I have never used type hinting in any form whasoever. Does it make testing more difficult? No, it does not "I have never used type hinting in any form whasoever" - so how can you be qualified at all to tell anything about the difference how it would be if you would have used it? Could the discussion be re-centered around the RFC at-hand rather than measuring "ego"? It seems that any thread that has both rhsoft and Tony involved devolves into a competition of opinion without much attempt to meet in the middle or understand one another. Thanks. = Any attempt to make typehinting (or type enforcement as it has now become) is simply adding complications to the language which do not provide benefits to the greater PHP community, just a minority of poor coders who want the language to trap the bugs that they create in their code. There are some of us out there who are capable of writing bug-free code without type enforcement, so this RFC (and anything else connected with type hinting/enforcement) is something we don't need to use, therefore it has no benefits for us. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
wrote in message news:e425ecf3-4ef8-826d-bf4c-3c7b588e1...@rhsoft.net... Am 31.12.2017 um 11:27 schrieb Tony Marston: "Michael Morris" wrote in message news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dnbswf9csuyntyn8x...@mail.gmail.com... On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <les...@lsces.co.uk> wrote: Not being able to vote, many of us have no option to complain about the way things are going. Currently there seems to be several styles of PHP form the nice and simple untyped version I moved to from very strictly typed hard compiled code I'd been using up until then, through to current code which is reliant on third party things like PSR and Composer and expects only strictly typed PHP. This is born of the fact that while ignoring datatype makes learning PHP easier, it makes using it harder - especially when testing. I strongly disagree. I have been using PHP since 2001 and I have never used type hinting in any form whasoever. Does it make testing more difficult? No, it does not "I have never used type hinting in any form whasoever" - so how can you be qualified at all to tell anything about the difference how it would be if you would have used it? I know that it would take a HUGE amount of effort to go through my massive code base to put typehints on every function and method, but for what benefit? Unless I can measure a definite performance gain then the lack of benefits would not justify the cost. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
wrote in message news:7482b9d4-d487-8c0f-1f92-2e8fef68d...@rhsoft.net... Am 31.12.2017 um 11:24 schrieb Tony Marston: Some of us are clever enough to write code that doesn't have those types of bug in the first place. I developed my framework in PHP4 before type hints even existed, and I developed a large enterprise application with that framework which is now being sold to large corporations all over the world. That codebase has moved from PHP 4 through all versions of PHP 5 and is now running on PHP 7.1. During these upgrades I have only changed my code to deal with what has been deprecated, and I have never bothered with any of those new optional extras (such as typehints) unless I have been convinced that the effort of changing my code has measureable benefits. well my codebase dates back to 2002 but is stricted-typed in the meantime - and now? PHP was never strictly typed from the start, and I have always loved the flexibility that this provided. I have never felt the urge to use typehints (or type enforcement that it has now become)and any potential bugs that this may create are quickly identified and resolved during my testing. The idea that typehints provide benefits to the whole PHP community is completely bogus. It only provides apparent benefits to those programmers who have moved from a strictly type language to PHP and who feel lost without the crutch that a strongly typed language seems to provide. I work faster with a dynamically and weakly typed language, so speed of development is far more important to me. Any so-called bugs are detected and fixed during the testing phase, so I don't want the language being slowed down performing checks that I don't want. nosense - after 15 years PHP andmoved everything to strict_types in 2017 (the current year) you can't accuse me that i have recebtly moved from a strongly typed language to PHP and felt lost all the years before Just because a whole load of new features have been added to the language does not mean that I should use them. They are entirely optional, and I choose NOT to use them unless I am convinced that the benefits are worth the effort. you think you work faster because you even don't realize small bugs until they become large enough that you sit there and debug for hours while a type-error with a stacktrace would have shown the mistake at the begin including the root cause As I said previously, any such errors that may be caused by not using a strictly typed language are detected and fixed when I test my code. My main application has been in live use since 2008, and you can count on one hand the number of bugs which are reported each year. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
"Michael Morris" wrote in message news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dnbswf9csuyntyn8x...@mail.gmail.com... On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <les...@lsces.co.uk> wrote: Not being able to vote, many of us have no option to complain about the way things are going. Currently there seems to be several styles of PHP form the nice and simple untyped version I moved to from very strictly typed hard compiled code I'd been using up until then, through to current code which is reliant on third party things like PSR and Composer and expects only strictly typed PHP. This is born of the fact that while ignoring datatype makes learning PHP easier, it makes using it harder - especially when testing. I strongly disagree. I have been using PHP since 2001 and I have never used type hinting in any form whasoever. Does it make testing more difficult? No, it does not. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
wrote in message news:28ba9e6a-a3f2-2547-d294-f3a1710d5...@rhsoft.net... Am 30.12.2017 um 11:37 schrieb Lester Caine: On 30/12/17 09:16, Tony Marston wrote: You are missing the point. If an RFC is so badly written that someone does not understand it, or understand what benefits it is supposed to provide, then there is no point in up-voting it if i don't undrstand it i don't vote at all - that's the point not up not down If you can't understand it then you cannot tell what benefit it gives to the greater PHP community, and if you cannot see that it provides any benefit then you should vote it DOWN. The 'greater PHP community' I continue to support is still only looking for a simply life, but each iteration of PHP7 is just making things more and more complex, which is why I STILL have not switched off PHP5 and 5.4 and earlier is still running a large percentage of sites. Just what percentage of the wider community thinks that strict typing is giving an essential benefit? If there was a groundswell for typing then perhaps we would not have this continual debate on just how to jam a little more of a move that way and get on with a version of PHP that is only typed. Then for one can simply avoid it ... who thinks it don't give you a benefit? for new code it's the best you can do do get it as bugfree as possible and fro old code you still are not forec to any typehints and for migration you have weak types too sorry, but discuss end of 2017 if types was a goof d idea and talk about the 'greater community' but still run PHP5? in the meantime I have changed *everything* written in the last 15 yeas to strict_types=1 and type hints everywhere - you find so much potential bugs that it's worth Some of us are clever enough to write code that doesn't have those types of bug in the first place. I developed my framework in PHP4 before type hints even existed, and I developed a large enterprise application with that framework which is now being sold to large corporations all over the world. That codebase has moved from PHP 4 through all versions of PHP 5 and is now running on PHP 7.1. During these upgrades I have only changed my code to deal with what has been deprecated, and I have never bothered with any of those new optional extras (such as typehints) unless I have been convinced that the effort of changing my code has measureable benefits. The idea that typehints provide benefits to the whole PHP community is completely bogus. It only provides apparent benefits to those programmers who have moved from a strictly type language to PHP and who feel lost without the crutch that a strongly typed language seems to provide. I work faster with a dynamically and weakly typed language, so speed of development is far more important to me. Any so-called bugs are detected and fixed during the testing phase, so I don't want the language being slowed down performing checks that I don't want. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
wrote in message news:320cb1b3-222b-2b21-6c39-8d9ea539b...@rhsoft.net... Am 30.12.2017 um 10:16 schrieb Tony Marston: wrote in message news:f48976dd-589f-e88e-37ba-38096c3a3...@rhsoft.net... You are missing the point. If an RFC is so badly written that someone does not understand it, or understand what benefits it is supposed to provide, then there is no point in up-voting it if i don't undrstand it i don't vote at all - that's the point not up not down If you can't understand it then you cannot tell what benefit it gives to the greater PHP community, and if you cannot see that it provides any benefit then you should vote it DOWN. Common sense should dictate that you only vote it UP when you are convinced that it will provide something of benefit. If you don't vote at all you are admitting that you are clueless, or don't care, in which case you are not preventing a bad idea from being accepted. If it later turns out that it was a crock of sh*t then you will be partly to blame because you didn't have the intelligence to see it as such and didn't speak up. If you don't understand an RFC then not only do you not understand the benefits that it can provide, you also don't understand the damage that it can cause. frankly, in the real world when you don't understand what some people are talking about you don't join and say "no, you are wrong" - you either shut up or ask again but you don't step in yelling "no!" It is not about an idea being right or wrong, it is about adding something new to the language. If you are not convinced that it will add value to the language then you should vote it down. Not voting either way because you don't understand the RFC or its proposed benefits just shows that you aren't qualified to vote on anything. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
wrote in message news:f48976dd-589f-e88e-37ba-38096c3a3...@rhsoft.net... Am 29.12.2017 um 09:04 schrieb Tony Marston: wrote in message news:4b55eed1-8656-ff70-e4e9-ad5e40213...@rhsoft.net... Am 29.12.2017 um 00:21 schrieb Larry Garfield: Correct. Union types I've always seen presented as offering both union and intersection. There are cases where union is great, and where it's kinda silly. There are cases where intersect is great, and where it's kinda silly. Most of the anti- arguments I've seen for "union types" have fixated on "int && string is meaningless, and Foo || Bar is bad design, so union types are bad!" Entirely ignoring the flip side, which is int || string (valid use cases) and Foo && Bar (many many valid use cases) well, that explains why the same person which hase a usecase for a "scalar" pseudo-type donw-votes https://wiki.php.net/rfc/union_types but it makes his vote not logical at all frankly the only valid reasons to down-vote something should be technical ones which matters for the PHP core itself and not "i don't understand a feature hence nobody should have it" You are missing the point. If an RFC is so badly written that someone does not understand it, or understand what benefits it is supposed to provide, then there is no point in up-voting it if i don't undrstand it i don't vote at all - that's the point not up not down If you can't understand it then you cannot tell what benefit it gives to the greater PHP community, and if you cannot see that it provides any benefit then you should vote it DOWN. Common sense should dictate that you only vote it UP when you are convinced that it will provide something of benefit. If you don't vote at all you are admitting that you are clueless, or don't care, in which case you are not preventing a bad idea from being accepted. If it later turns out that it was a crock of sh*t then you will be partly to blame because you didn't have the intelligence to see it as such and didn't speak up. If you don't understand an RFC then not only do you not understand the benefits that it can provide, you also don't understand the damage that it can cause. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
wrote in message news:4b55eed1-8656-ff70-e4e9-ad5e40213...@rhsoft.net... Am 29.12.2017 um 00:21 schrieb Larry Garfield: Correct. Union types I've always seen presented as offering both union and intersection. There are cases where union is great, and where it's kinda silly. There are cases where intersect is great, and where it's kinda silly. Most of the anti- arguments I've seen for "union types" have fixated on "int && string is meaningless, and Foo || Bar is bad design, so union types are bad!" Entirely ignoring the flip side, which is int || string (valid use cases) and Foo && Bar (many many valid use cases) well, that explains why the same person which hase a usecase for a "scalar" pseudo-type donw-votes https://wiki.php.net/rfc/union_types but it makes his vote not logical at all frankly the only valid reasons to down-vote something should be technical ones which matters for the PHP core itself and not "i don't understand a feature hence nobody should have it" You are missing the point. If an RFC is so badly written that someone does not understand it, or understand what benefits it is supposed to provide, then there is no point in up-voting it. You may contrive a use case where it provides a small benefit, but if that use case is so limited or so obscure that it does not apply to a significant number of developers then that RFC should be voted down simply because it does not provide any significant benefits. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
""Michal Brzuchalski"" wrote in message news:cabdc3wrz8qu_hgsbtjgbwwct8yplxgchonee9nijkwcderu...@mail.gmail.com... 13.12.2017 11:44 "Tony Marston" <tonymars...@hotmail.com> napisal(a): ""Michal Brzuchalski"" wrote in message news:CABdc3WpomNLz+vX_m0B0wQ3u cimiw8xw4ea_sgd-ptdgfv-...@mail.gmail.com... 2017-12-13 1:16 GMT+01:00 Andreas Hennings <andr...@dqxtech.net>: Why? Because users use PSR-4 so then they're src folder looks more like: ? You are assuming that everybody is using PSR-4. That is a wrong assumption to make. I didn't say everybody at all! Please read carefully. I DID read carefully. You wrote "users use PSR-4" and not "those users who use PSR-4". You did not specify a subset of users, so this implies all users. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
""Michal Brzuchalski"" wrote in message news:cabdc3wpomnlz+vx_m0b0wq3ucimiw8xw4ea_sgd-ptdgfv-...@mail.gmail.com... 2017-12-13 1:16 GMT+01:00 Andreas Hennings <andr...@dqxtech.net>: Why? Because users use PSR-4 so then they're src folder looks more like: ? You are assuming that everybody is using PSR-4. That is a wrong assumption to make. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
"Andreas Hennings" wrote in message news:CAH0Uv3FnYf_c7in4_6AmDO5pUZHsgU0m5scjU5oRz2kTAJ=+b...@mail.gmail.com... I agree with all of Stanislav's emails in this thread so far. On 12 December 2017 at 14:43, Nikita Popov <nikita@gmail.com> wrote: On Tue, Dec 12, 2017 at 8:46 AM, Stanislav Malyshev <smalys...@gmail.com> wrote: PHP as a language should not assume that someone is using Composer correctly. Or even using Composer at all. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC - Array Of for PHP 7
wrote in message news:0f4b93e2-d8fa-edbd-e1ff-502101839...@rhsoft.net... well, you always ignore anything but your opinion and the next step is calling people "except if you are a nit-picking, anal retentive OCD sufferer" because they don't follow your argumentation as it happened in several threads The whole point of my argument is that I believe it is wrong to fill the language with clever functions which do nothing but save a few keystrokes for those developers who are too lazy to type out a few simple lines of userland code. Filling the language with such bloat has a detrimental effect on everybody who uses the language, and especially on the core developers who have to maintain that bloat. You stop telling me that you don't like my opinion and I will stop telling you that I don't like your opinion. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC - Array Of for PHP 7
"Alice Wonder" wrote in message news:572d0e30-7214-0842-6624-7647514b9...@librelamp.com... On 11/07/2017 02:21 AM, Tony Marston wrote: Some things are so obvious that they do not need scientific proof. Some things that appear obvious are incorrect, especially when bias enters. Scientific proof brings human bias out of the equation, or at least reduces it. For example, in a motor vehicle the power-to-weight ratio is important as it affects engine performance and fuel economy. In other words, for a given engine size the lower the weight of the car and the better the fuel consumption. The more weight you add the lower the performance. Your car has a heater which you only use when it's cold. It also has an air conditioner for when it's hot. It has windscreen wipers, and a motor, for when it's raining. When the temperature is mild and it's not raining it means that you are not using any of this equipment, yet you are still carrying their weight, and this weight is affecting your car's performance. I do not have to supply any figures as proof as the car manufacturers keep telling us that cars that weigh less perform better, which is why they try to reduce the weight of as any components as possible. You then give an example for which every first year physics students has done experiments which use science to demonstrate it (namely demonstrating how weight impacts friction) Sorry but if something is obvious then it should be able to test in a scientific experiment. Individuals do not need to provide proof of this claim as it has already been made by the motor manufacturers who have provided their own proof. That is why they spend fortunes trying to reduce the weight of every single component in their cars. It should also be obvious to every first year student that if a program contains code that is rarely or never used then carrying around the "weight" of that code has a detrimental effect. The code has a bigger footprint, therefore takes up more memory and is slower to load. It also increases the burden on those who maintain that code as they have to consider every piece of code without knowing how often it is used. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC - Array Of for PHP 7
"Stephen Reay" wrote in message news:562e5c38-b46b-449d-8676-8699b59dd...@koalephant.com... On 7 Nov 2017, at 17:21, Tony Marston <tonymars...@hotmail.com> wrote: I was around when that happened, so I know what I'm talking about. I'm not going to get into the whole "it can be done in userland why do we need it in core" debate, because honestly that's a silly discussion to have when you don't have any planned implementation to discuss the merits of. So you are quite happy to see the language filled with complicated features which do nothing but save a few keystrokes or lazy developers? The only reason I wanted to respond was your last line, quoted above. Being "around" when something happens means zero as far as credibility or knowledge. The captain of the titanic was "around" when it sank. Irrelevant analogy. If you read https://en.wikipedia.org/wiki/Reduced_instruction_set_computer you will see the advantage of getting rid of complex and specialised instructions and concentrating on simple and general instructions. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC - Array Of for PHP 7
wrote in message news:748869f7-13bb-5bdd-6fec-399a33b79...@rhsoft.net... Am 06.11.2017 um 12:09 schrieb Tony Marston: wrote in message news:55fb932f-7f61-33eb-1fd9-aa425bc6f...@rhsoft.net... Am 05.11.2017 um 11:24 schrieb Tony Marston: wrote in message news:d70cc49d-c397-3f09-d08d-b79b31014...@rhsoft.net... it depends on the implementation and just beause you say so does not prove anything and even if you need to measure, optimize and make decisions based on technical facts - what you do is "mimimi i say" I have worked on software which provided lots of different options, which means that you have to keep testing if an option is being used or not. This is an overhead whether you like it or not. maybe your implementation was bad Everybody knows that carrying around code which is either rarely used or not used at all is an overhead everybody knows that claims without measure the impact are worthless Some things are so obvious that they do not need scientific proof. For example, in a motor vehicle the power-to-weight ratio is important as it affects engine performance and fuel economy. In other words, for a given engine size the lower the weight of the car and the better the fuel consumption. The more weight you add the lower the performance. Your car has a heater which you only use when it's cold. It also has an air conditioner for when it's hot. It has windscreen wipers, and a motor, for when it's raining. When the temperature is mild and it's not raining it means that you are not using any of this equipment, yet you are still carrying their weight, and this weight is affecting your car's performance. I do not have to supply any figures as proof as the car manufacturers keep telling us that cars that weigh less perform better, which is why they try to reduce the weight of as any components as possible. It is the same with software. The more code you carry around that is not being used then the worse it will perform. Esoteric code which uses clever features to perform tasks which can already be performed with simple code is, IMHO, an unnecessary complication which benefits only those lazy programmers who are obsessed with reducing the number of keystrokes. Taking out the rarely used complicated stuff and concentrating on making the commonly used stuff as fast and efficient as possible is what drove the efforts in the RISC architecture. I was around when that happened, so I know what I'm talking about. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC - Array Of for PHP 7
wrote in message news:55fb932f-7f61-33eb-1fd9-aa425bc6f...@rhsoft.net... Am 05.11.2017 um 11:24 schrieb Tony Marston: wrote in message news:d70cc49d-c397-3f09-d08d-b79b31014...@rhsoft.net... it depends on the implementation and just beause you say so does not prove anything and even if you need to measure, optimize and make decisions based on technical facts - what you do is "mimimi i say" I have worked on software which provided lots of different options, which means that you have to keep testing if an option is being used or not. This is an overhead whether you like it or not. maybe your implementation was bad Everybody knows that carrying around code which is either rarely used or not used at all is an overhead. That's what the 80-20 rule demonstrates. Adding something to the language core for something which can already be done easily is userland code, but with slightly fewer keystrokes, does not provide any benefits for the majority of developers who have already written those few lines of code. This is a classic example of pandering to the whims of a tiny minority to the detriment of the majority. There is a big difference between adding something to the language core which everyone has to load into memory, and having something in an extension which is entirely optional. or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 *all* have new features and where *faster* then the previous version - frankly you are raising alarm for no reason Can you prove that each new version was faster? Where is your evidence? everbody knows that and can benchmark it at any time, but if it makes you happy that others are doing your homework https://www.phpclasses.org/blog/post/493-php-performance-evolution.html PHP 7 is faster than PHP 5 for various reasons, such as it being 64bit instead of 32bit WTF, only in your windows world which don't matter that much, everywhere else x86_64 is normal for many years and each software Excuse me! Some of the major clients who use my ERP application only use Windows servers, so your claim that Windows does matter is completely bogus. how does that change the fact that your claim "such as it being 64bit instead of 32bit" is nonsense when most of the benchamrks and production servers out there are running PHP on x86_64 with 86_64 builds for a decade now? 64bit builds of PHP 5 for Windows were all marked as experimental, therefore not guaranteed to be as reliable as the 32bit versions. The "experimental" tag was only removed for PHP 7. and improvements made to the engine itself, such as the AST. I submit that it would be smaller and faster if it did not have to carry around so much dross. Adding something to the core language just to save a few keystrokes for a small number of lazy developers falls into the category of dross you ignored that practicaly *every* PHP version before PHP/ was faster *and* had new features compared to the previous one Just think how much faster and easier to maintain it would be if all this save-a-few-keystrokes dross had not been added in the first place. again: unproven claim, but in your own world a hashtable probably is also not O(1) or you are just not capable to optimize software at all but then stop claim others aren't too Everybody knows that carrying around code which is either rarely used or not used at all is an overhead. That's what the 80-20 rule demonstrates. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC - Array Of for PHP 7
wrote in message news:d70cc49d-c397-3f09-d08d-b79b31014...@rhsoft.net... Am 04.11.2017 um 10:18 schrieb Tony Marston: wrote in message news:941fd347-4a17-78b6-1bd7-4a5519aa7...@rhsoft.net... Am 03.11.2017 um 11:33 schrieb Tony Marston: wrote in message news:6643d10b-8703-693c-15c2-da338022e...@rhsoft.net... Am 02.11.2017 um 10:55 schrieb Tony Marston: "Kalle Sommer Nielsen" wrote in message I fail to see how it offers "negative benefits to the vast number of programmers who are happy with the language as it currently exists", I If it's put into the language then it affects 100% of the users, but what percentage of the user base would actually take advantage of this feature? If it's only 1% then for the other 99% it's a complete waste of time how does any feature you don't use affect you? Because the language itself becomes bloated with the capabilities it has to offer, look for and deal with. This makes it bigger and slower unproven claim! It's pure common sense! You have to carry around the capability of doing something, then have tests everywhere to see if that capability is actually required or not at run-time. it depends on the implementation and just beause you say so does not prove anything and even if you need to measure, optimize and make decisions based on technical facts - what you do is "mimimi i say" I have worked on software which provided lots of different options, which means that you have to keep testing if an option is being used or not. This is an overhead whether you like it or not. There is a big difference between adding something to the language core which everyone has to load into memory, and having something in an extension which is entirely optional. or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 *all* have new features and where *faster* then the previous version - frankly you are raising alarm for no reason Can you prove that each new version was faster? Where is your evidence? PHP 7 is faster than PHP 5 for various reasons, such as it being 64bit instead of 32bit WTF, only in your windows world which don't matter that much, everywhere else x86_64 is normal for many years and each software Excuse me! Some of the major clients who use my ERP application only use Windows servers, so your claim that Windows does matter is completely bogus. and improvements made to the engine itself, such as the AST. I submit that it would be smaller and faster if it did not have to carry around so much dross. Adding something to the core language just to save a few keystrokes for a small number of lazy developers falls into the category of dross you ignored that practicaly *every* PHP version before PHP/ was faster *and* had new features compared to the previous one Just think how much faster and easier to maintain it would be if all this save-a-few-keystrokes dross had not been added in the first place. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC - Array Of for PHP 7
wrote in message news:941fd347-4a17-78b6-1bd7-4a5519aa7...@rhsoft.net... Am 03.11.2017 um 11:33 schrieb Tony Marston: wrote in message news:6643d10b-8703-693c-15c2-da338022e...@rhsoft.net... Am 02.11.2017 um 10:55 schrieb Tony Marston: "Kalle Sommer Nielsen" wrote in message I fail to see how it offers "negative benefits to the vast number of programmers who are happy with the language as it currently exists", I If it's put into the language then it affects 100% of the users, but what percentage of the user base would actually take advantage of this feature? If it's only 1% then for the other 99% it's a complete waste of time how does any feature you don't use affect you? Because the language itself becomes bloated with the capabilities it has to offer, look for and deal with. This makes it bigger and slower unproven claim! It's pure common sense! You have to carry around the capability of doing something, then have tests everywhere to see if that capability is actually required or not at run-time. There is a big difference between adding something to the language core which everyone has to load into memory, and having something in an extension which is entirely optional. or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 *all* have new features and where *faster* then the previous version - frankly you are raising alarm for no reason PHP 7 is faster than PHP 5 for various reasons, such as it being 64bit instead of 32bit, and improvements made to the engine itself, such as the AST. I submit that it would be smaller and faster if it did not have to carry around so much dross. Adding something to the core language just to save a few keystrokes for a small number of lazy developers falls into the category of dross. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC - Array Of for PHP 7
wrote in message news:6643d10b-8703-693c-15c2-da338022e...@rhsoft.net... Am 02.11.2017 um 10:55 schrieb Tony Marston: "Kalle Sommer Nielsen" wrote in message I fail to see how it offers "negative benefits to the vast number of programmers who are happy with the language as it currently exists", I If it's put into the language then it affects 100% of the users, but what percentage of the user base would actually take advantage of this feature? If it's only 1% then for the other 99% it's a complete waste of time how does any feature you don't use affect you? Because the language itself becomes bloated with the capabilities it has to offer, look for and deal with. This makes it bigger and slower. For example, if you have a vehicle which is capable of going anywhere, over every types of terrain, in every climate from sub zero to blisteringly hot then at any one time you are not using all the capabilities, yet you are still carrying the around. The core language should be kept lean and mean, and should only have new instructions added when (a) something cannot be done easily in userland code, and (b) when that something is of genuine use to a significant number of people. Complicating the language with something that can already be done with a few lines of userland code and which is desired by only a miniscule number of people does not fall into this category. i don't care about pdo and many other core extensions nor about namespaces, traits and so on - but they don't affect me at all -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC - Array Of for PHP 7
"Kalle Sommer Nielsen" wrote in message news:CAJW__o3QJOe6G3ybmBcoCU=fcadjzacgbktijrbm3rs8q0h...@mail.gmail.com... Hi Tony 2017-10-31 11:35 GMT+01:00 Tony Marston <tonymars...@hotmail.com>: This strikes me as being nothing more than a micro-optimisation that does nothing but pander to the laziness of certain programmers. Instead of having to write a few lines of code to validate something they want the language to do it for them. It may come as a surprise to some people, but being a programmer actually involves the writing of program code. It is not sufficient to express an idea and have the language fill in all the details as that forces the language to have to detect and deal with a myriad of possibilities. I do understand where you are coming from, but I don't necessarily agree on this topic. We can (hopefully) agree that programming language design is hard, I totally agree that compiler writing is hard, which is why I believe that only those things which are hard to do in userland code should be added to the language. because we need to determine how fine a line we should have between things thats an integral part of the language, its standard library or its extensions and how much power the programmer has in their arsenal to do crazy things. For me the rule is simple - if something can already be done quite easily in userland code then it should not be forced into the language just because a small number of developers wnat to save themselves a few keystrokes. Making the language more complicated than it need be leads to a maintenance burden both for the core developers and the application developers who now have to deal with a growing array of indeciferable shortcuts. If we boil things down, then we didn't really need the scalar type hints, PHP had been working perfectly fine for 20 years without it and while it does not add anything but a couple of checks at compile/runtime, its essentially "laziness of certain programmers" it becomes useful to. Another example is constant visibility modifiers in PHP 7.1. I think one of the advocates for features that are within that category you mention can sometimes be productivity and rid of boilerplate code. For this case with 'Array Of', I think it makes perfect sense to add with PHP7's improved type system on that regard, but thats my personal opinion. This type of checking can quite easily be done in userland code, so I see no reason why it should be built into the language. What percentage of userland developers would actually use such a feature? I wouldn't as I never pass around arrays of single types. I regularly use the $_POST array and a database record array which are both of mixed types. I would evaluate each proposed change to the language with a simple question - does it provide the greatest good to the greatest number? Considering the fact that this RFC will only benefit a miniscule minority of developers yet make the language more complicated, slower to run, and more difficult to maintain as more and more edge cases are identified as "bugs", it offers negative benefits to the vast number of programmers who are happy with the language as it currently exists. As such it fails that test and should be rejected. Tho you said its a micro optimization, would argue that (see [1]), it far from makes the code complicated, internally it doesn't add any complexity I disagree. The language has to be changed to recognise that type of argument, then it has to iterate through the array checking that every member is of the designated type. In other words the langage now has to do what you are doing with a few lines of userland code. and only adds a member to the arg_info, which is an unsigned char, it wouldn't do anything unless a type is specified anyway and the slower to run argument above is pretty void, sure it adds a few CPU instructions but its not something you will feel unless you are Facebook, in which case you already re-implemented the language on your own. I fail to see how it offers "negative benefits to the vast number of programmers who are happy with the language as it currently exists", I If it's put into the language then it affects 100% of the users, but what percentage of the user base would actually take advantage of this feature? If it's only 1% then for the other 99% it's a complete waste of time. myself don't like PDO, so I just use mysqli instead, great. If its not something that affects the programmer and the programmers code continue to run, I fail to see how it negatively impacts the vast majority. It has complications in the language that are not used. Have you ever heard o the 80-20 rule? This is where 80% of the usage is simple and 20% is complicated, but that complicated 20% takes up 80% of the programming effort. I was around in the 1980s during the switch to RISC (Reduced Instruction Set Computers) where
[PHP-DEV] Re: RFC - Array Of for PHP 7
""Michal Harezlak"" wrote in message news:caltzvrkflncw4+d-fu4cp2rmoscf77vzfz4f1cuvp3vymzk...@mail.gmail.com... Hallo, I would like to create a RFC for PHP 7, but the same RFC was created and declined 3 years ago for PHP 5.4. PHP 7 support much better type hinging so I think this RFC should be voted again. What should I do? Should I create the RPF in common way? Link to mentioned RFC: https://wiki.php.net/rfc/arrayof This strikes me as being nothing more than a micro-optimisation that does nothing but pander to the laziness of certain programmers. Instead of having to write a few lines of code to validate something they want the language to do it for them. It may come as a surprise to some people, but being a programmer actually involves the writing of program code. It is not sufficient to express an idea and have the language fill in all the details as that forces the language to have to detect and deal with a myriad of possibilities. I would evaluate each proposed change to the language with a simple question - does it provide the greatest good to the greatest number? Considering the fact that this RFC will only benefit a miniscule minority of developers yet make the language more complicated, slower to run, and more difficult to maintain as more and more edge cases are identified as "bugs", it offers negative benefits to the vast number of programmers who are happy with the language as it currently exists. As such it fails that test and should be rejected. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Pre-draft for PipeOp v2
"Rowan Collins" wrote in message news:f9001e2a-8f13-d4ba-f514-f18dc1e4f...@gmail.com... On 28/09/2017 20:07, Levi Morrison wrote: The brace style is concise, nicely delimits the expression, and seems the clearest for me to read because the symbols don't dominate. This is something that I tried to push for in previous discussions - I've never liked the syntaxes where the expression floats away from the operator, and you have to work out where it ends. The counter-argument I got was that some people actually like writing things like this, although I'm not entirely clear why: fn($x) => fn($y) => in_array($x, $y) Just because some people would like to write code like this does not make it acceptable for the majority of the programming community. You should never forget that the primary aim of a programmer is to write code which can be read by a human, and only incidentally to be executed by a machine (H. Abelson and G. Sussman in "The Structure and Interpretation of Computer Programs", 1984). Some people complain that PHP is too verbose, so they strive to replace long words, or groups of words, with abbreviations or even symbols. This, IMHO, converts a readable program into a bunch of hieroglyphics and should therefore be avoided. I think there should be a rule which states that if something can already be done with 5 lines or less of userland code then it should not be built into the core language as it would be adding unnecessary complications that would only benefit a small minority of programmers but would be to the detriment of the majority. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
wrote in message news:489a2ea0-7b24-fedd-e496-ee662a605...@rhsoft.net... Am 25.09.2017 um 11:41 schrieb Tony Marston: The fact that some people write "do_something" or "do_Something" or "Do_Something" or even "DO_SOMETHING" and it points to a single function because of case insensitivity does NOT cause a genuine problem - except in the minds of a few nit-picking, anal retentive OCD sufferers wow - sue your dealer! I'm sorry, but reading code where the case of a word changes the meaning of that word will make that code LESS readable, not MORE how comes when the same word is written over the whole codebase *identically* that for it is harder to read? That is not what I said. Taking the same function name and allowing different versions to exist with different implementations would be a recipe for disaster whereas the situation which you are complaining about is nothing more than mildly annoying - except if you are a nit-picking, anal retentive OCD sufferer in which case it signals the arrival of the four horsemen of the apocalypse. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
wrote in message news:8bc2e400-5edd-db9c-1163-ec9878e9e...@rhsoft.net... Am 24.09.2017 um 11:36 schrieb Tony Marston: If you wish to enforce case sensitivity in projects which you control then go ahead. Just don't try to enforce it on everybody else. that thread was about the PHP core and NOT case-sensitive where you called people "OCD sufferers" - so don't play stupid games here when everybody can access the list archive or is knowing your attitude anyways - you have lost that game The fact that some people write "do_something" or "do_Something" or "Do_Something" or even "DO_SOMETHING" and it points to a single function because of case insensitivity does NOT cause a genuine problem - except in the minds of a few nit-picking, anal retentive OCD sufferers. The REAL problem occurs when you make those four mixtures of case mean point to different functions which do different things. If you cannot tell the difference between a perceived problem and a real problem your attempts to shut me up will continue to fail. https://www.mail-archive.com/internals@lists.php.net/msg91537.html https://www.mail-archive.com/internals@lists.php.net/msg91562.html and frankly people like you arguing about code consistency are fired here from one the to the next because theri inability to write well cocumentend and readable quality code at all and they are instead coding timebombs I'm sorry, but reading code where the case of a word changes the meaning of that word will make that code LESS readable, not MORE. it's one thing when you write your private crap but from the point you want your code used by somebody else you have to play with that rules I repeat, if you want to enforce case sensitivity in those projects which you control then go ahead, but don't try to enforce it on the whole programming community. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
hould be depricated, but enabled for one major release with an init flag -- just as was done for register_globals. That would give everyone a couple of years to tidy their code up. Do you realise how much of a BC break this would be? For what benefit? Just to satisfy your idea of "purity"? Then kill case insensitve anything in PHP [[ other than the likes of strcasecmp() ]]. **OK: MySQL has a switch to make table names, etc, case insensitive - but enabling that means a lot of testing to ensure that nothing else breaks. $$ I don't want to be rude about her, so maybe I ought to use a different group of clueless people, politicians perhaps ? :-) -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
wrote in message news:caba6370-7531-7c51-3900-434611d00...@rhsoft.net... Am 22.09.2017 um 10:21 schrieb Tony Marston: wrote in message news:064eafcb-e42f-cfeb-76f1-e2c5aec0e...@rhsoft.net... Am 19.09.2017 um 11:24 schrieb Tony Marston: If the single character "ß" represents two "s" characters joined together, then the uppercase equivalent should also be a single character which looks like two "S" characters joined together. If it is not possible to write code which deals with these exceptions, then one alternative would be to remove these exceptions remove from where? from the reality? If the lowercase character "ß" causes so many problems because it has no proper equivalent in uppercase then it should be removed from the list of valid characters. Either that or provide a single uppercase character - which is what that wikipedia article you quoted says actually happened this year jesus christ the german language DID NOT have a uppercase ß in the real world until recently but had the lowercase ß virtually forever how do you imagine "removeed from the list of valid characters" in that case - frankly that paragraph above shows clearly that you should stop to argue about this topic at all Just because my opinion differs from yours does not give you the right to demand that I stop expressing it surely, in my opinion you don't understand the topic you are talking about and repeating the same questionable stuff again and again and as you are allowed to express your opinion i am allowed to express mine the way you argued about how code consistency don't matter says it all It is your definition of "consistency" that I object to. Consistency with what? Code that abandons case insensitivity "just to be consistent" is consistently bad because it removes the feature called "case insensitivity" that we humans have become used to since we began to read and write. I have been working in the computer industry since the early 1970s on a variety of mainframe, mini- and micro-computers, and a variety of languages. and this was all case insensitive. It was only the invention of unix which threw a spanner in the works. as you call everybody which demands that code all over a poject or company has to follow a common coding style "OCD sufferers" - but hey, the others are all ghost drivers and should turn around If you wish to enforce case sensitivity in projects which you control then go ahead. Just don't try to enforce it on everybody else. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
wrote in message news:064eafcb-e42f-cfeb-76f1-e2c5aec0e...@rhsoft.net... Am 20.09.2017 um 11:30 schrieb Tony Marston: wrote in message news:098adca8-6897-929d-90e4-cc464f0e2...@rhsoft.net... Am 19.09.2017 um 11:24 schrieb Tony Marston: If the single character "ß" represents two "s" characters joined together, then the uppercase equivalent should also be a single character which looks like two "S" characters joined together. If it is not possible to write code which deals with these exceptions, then one alternative would be to remove these exceptions remove from where? from the reality? If the lowercase character "ß" causes so many problems because it has no proper equivalent in uppercase then it should be removed from the list of valid characters. Either that or provide a single uppercase character - which is what that wikipedia article you quoted says actually happened this year jesus christ the german language DID NOT have a uppercase ß in the real world until recently but had the lowercase ß virtually forever how do you imagine "removeed from the list of valid characters" in that case - frankly that paragraph above shows clearly that you should stop to argue about this topic at all Just because my opinion differs from yours does not give you the right to demand that I stop expressing it. To me the situation is quite simple. - Human beings have grown accustomed to case-insensitive world, and to remove this standard feature would cause great disruption. - Some people may think that function names written as "do_something" or "do_Something" or "Do_Something" which mean the same thing are wrong, but that is no more than simply irritating for the nit-picking minority. If you made those names mean different thing then that would be worse than wrong, it would be criminally insane. - Rather than making constants case sensitive it would be better to leave then as case insensitive, but prevent the creation of a constant with the same name but different case. This would make it consistent with function and method names. - If the use of some non-ASCII characters in function names causes case folding problems then I see two choices - either disallow non-ASCII characters in function names, or allow Unicode characters but disallow any which have case folding problems. Simply telling me that it would be easier to make the entire language case sensitive as there are "difficulties" with case folding of a minute number of unicode characters is not good enough. Programmers are supposed to solve problems for their users, not create them. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
wrote in message news:098adca8-6897-929d-90e4-cc464f0e2...@rhsoft.net... Am 19.09.2017 um 11:24 schrieb Tony Marston: If the single character "ß" represents two "s" characters joined together, then the uppercase equivalent should also be a single character which looks like two "S" characters joined together. If it is not possible to write code which deals with these exceptions, then one alternative would be to remove these exceptions remove from where? from the reality? If the lowercase character "ß" causes so many problems because it has no proper equivalent in uppercase then it should be removed from the list of valid characters. Either that or provide a single uppercase character - which is what that wikipedia article you quoted says actually happened this year. have fun, it becomes even more complexer and currently it's in discussion where to place the uppercase on a keyboard https://en.wikipedia.org/wiki/%C3%9F#Capital_form > If the single character "ß" represents two "s" no, until short ago there where just no uppercase one and that's only about german - you still missed *to prove* "Removing case insensitivity completely is not a proper solution as it removes a feature that we humans have been used to for decades" When we search for a word in a dictionary we do not need to specify case as that is irrelevant, so "sausage" is the same as "SAUSAGE". There are words which can have different meanings depending on the context, such as "this cup is made of china" and "I am going to China", but provided that the context remains the same then case is irrelevant. When it comes to software case insensitivity has been the standard since day 1. When searching for a file in MS Windows you do not have to specify case as it is not possible to have different files with the same name but different mixtures of case. When searching for a word or phrase in a text editor it is not necessary to specify case, although some editors include an option to make the search case sensitive. since i know nobody right in his mind which writes inconsistent code where this is a real world problem and if someone writtes "my_function", "MY_function" and "my_Function" in his code and don#t stop that nosnese he simply get fired That may be uncool, but the only problem it causes is in the tiny minds of OCD sufferers. By making the language case sensitive and allowing "my_function", "MY_function" and "my_Function" to be defined as separate functions with separate implementations would be inviting total disaster. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
""Christoph M. Becker"" wrote in message
news:e8590cd8-8e85-9f2f-470f-f612b2b0f...@gmx.de...
On 18.09.2017 at 11:40, Tony Marston wrote:
I have already acknowledged that the same word can have a different
meaning in a different context, so the word "china" has a different
meaning in "I am going to China" and "this is made from china". However,
in the same context changes in case are irrelevant:
"I AM GOING TO CHINA" is the same as "i am going to china".
"THIS IS MADE FROM CHINA" is the same as "this is made from china".
The same written (and this is what we're talking about; pronunciation is
irrelevant here) English word can have different meaning in the same
context, too. One may say "This is nice!" (to show appreciation) and
"This is Nice!" (to refer to the city). Also many professions which are
also common names have the same issue ("This is the miller" vs. "This is
the Miller"). You may recognize the common pattern, namely that proper
names are capitalized in English. In German, and likely some other
languages as well, all nouns are capitalized, so there are obviously
many more such cases.
You are talking about slight differences in human-to-human communication
which is totally irrelevant. This topic is about switching case in software,
and in such cases those differences are irrelevant. If my software switches
case so that "this is nice" becomes "THIS IS NICE" or vice versa, then it
does not matter one jot that "nice" could mean a place, or something
pleasant, or even the initials of The National Institute for Health and Care
Excellence. Inside the computer it does not matter.
The fact that "title case" means different things in different languages is
irrelevant. If it is implemented in the standard (i.e English) way then it
does not make the sentence unreadable in those foreign languages, so those
foreign johnnys should learn to live with it.
However, that does not necessarily mean that I prefer case-sensivity
over case-insensivity, but it would indeed greatly simplify the
implementation, since case-folding is a rather complex issue.
I have always been taught that there are only two ways of doing a job -
either "properly" or "not at all". The exceptions in switching between upper
and lowercase should be built into the Unicode engine then the problem is
solved properly. Removing case insensitivity completely is not a proper
solution as it removes a feature that we humans have been used to for
decades. This would be a case where the cure is even worse than the disease.
For
instance, the German lower-case letter "ß" is traditionally written as
"SS" in upper-case. So if I would define('STRASSE', $value, true), I
might expect to be a ble to write "Straße". That wouldn't apply to
"KRESSE", though, which has to be written as "Kresse". See also
<https://www.w3.org/International/wiki/Case_folding>.
If the single character "ß" represents two "s" characters joined together,
then the uppercase equivalent should also be a single character which looks
like two "S" characters joined together. If it is not possible to write code
which deals with these exceptions, then one alternative would be to remove
these exceptions.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"niel" wrote in message news:f75fe28a-9002-401c-f863-4462251e2...@blueyonder.co.uk... On 16/09/17 11:56, Tony Marston wrote: ""Christoph M. Becker"" wrote in message news:7f14af9e-cd8c-3a73-e487-7219a7630...@gmx.de... On 16.09.2017 at 11:16, Tony Marston wrote: There is no such thing as "Pissed with a capital 'P' means drunk" and "pissed with a lowercase 'p' means unhappy". "It's Nice" vs. "It's nice". "Nice" pronounced "nyce" means the same thing regardless of case. "Nice" pronounced "neece" is a place name, so "I went to Nice" means the same thing as "I WENT TO NICE". You could even write it as "i went to nice" and people would understand what you meant. The idea that the entire universe should have to change its rules regarding switching between upper and lowercase just to satisfy a few anomalies concocted by the master race is laughable. Godwin's law fulfilled, again. Sad. Excuse me, but I have not mentioned anywhere that Austrian corporal or his political persuasions, so this law has not been fulfilled. Unless you are telling me that all German people are cast from the same mould. Try China vs. china One is a country, the other is a type of ceramic. I have already acknowledged that the same word can have a different meaning in a different context, so the word "china" has a different meaning in "I am going to China" and "this is made from china". However, in the same context changes in case are irrelevant: "I AM GOING TO CHINA" is the same as "i am going to china". "THIS IS MADE FROM CHINA" is the same as "this is made from china". -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
""Christoph M. Becker"" wrote in message news:7f14af9e-cd8c-3a73-e487-7219a7630...@gmx.de... On 16.09.2017 at 11:16, Tony Marston wrote: There is no such thing as "Pissed with a capital 'P' means drunk" and "pissed with a lowercase 'p' means unhappy". "It's Nice" vs. "It's nice". "Nice" pronounced "nyce" means the same thing regardless of case. "Nice" pronounced "neece" is a place name, so "I went to Nice" means the same thing as "I WENT TO NICE". You could even write it as "i went to nice" and people would understand what you meant. The idea that the entire universe should have to change its rules regarding switching between upper and lowercase just to satisfy a few anomalies concocted by the master race is laughable. Godwin's law fulfilled, again. Sad. Excuse me, but I have not mentioned anywhere that Austrian corporal or his political persuasions, so this law has not been fulfilled. Unless you are telling me that all German people are cast from the same mould. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Alain Williams" wrote in message news:20170916094055.gm8...@phcomp.co.uk... On Sat, Sep 16, 2017 at 10:29:26AM +0100, Tony Marston wrote: People keep telling me that switching between upper and lower case for all character sets in the universe is not 100% simple because of a small number of exceptions. So what? Identify the exceptions and write code which deals with them. Thereby increasing the complexity of the PHP engine - which means more bugs and slower execution. It also makes it harder for the user to understand: they need to get their heads round the corner cases. There should be no need to complicate the entire PHP engine. Just fix the UNICODE exceptions so that strtoupper() and strtolower() work properly for that small number of peculiar character sets. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
wrote in message news:b7f14ab8-feed-b3d8-293a-ac658adab...@rhsoft.net... Am 16.09.2017 um 11:36 schrieb Tony Marston: wrote in message news:bd24d73e-4999-ffd9-ce03-6b7629037...@rhsoft.net... after i switched every piece of code i write the last 15 years tpo strict-types, typhe-hints and return-types everywhere while also write a complete autotest suite you can't tell me it costs more time to fix such case warnings by read the log and it would take longer as all your discussions - so why don't you stop it? Just because you disagree with what I have to say does not mean that you can tell me to stop saying it. If you want me to accept that you can have a different opinion then you should extend the same courtesy to me. you stated your opinion often enough as you did in the thread where you explained us that code consistency don't matter for you - in both cases nobody agreed Consistency with what? Why should I change the way that I code just to be consistent with somebody else's bad decisions? Why should I have to take someone else's personal preferences and treat them as if they were cast in stone and handed down from the mountain top? -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
wrote in message news:bd24d73e-4999-ffd9-ce03-6b7629037...@rhsoft.net... Am 15.09.2017 um 16:58 schrieb Tony Marston: wrote in message news:5fe274c1-36de-e650-fd2c-bc4f9caf3...@rhsoft.net... Am 15.09.2017 um 11:25 schrieb Tony Marston: You are missing a third option - Microsoft languages are case-preserving. This is where the IDE ensures that every use of a word is automatically switched to the case used in its original definition. This makes it impossible to use the same word with a different case. a sane IDE for PHP does exactly the same for many many years if you don't insist to change it manually - when you manage that you functions are written all over your codebase with different uppercase/lowercase the problem is looking at you from a mirror every morning How many IDEs out there for PHP? What percentage of them support case preserving? Zend Studio didn't when I used it. PHPEd doesn't i need to see one which don't make autocompletion with preserved case and if you don't use it because you like typos in general your fault You are avoiding the question. You state that dealing with this situation should be done within the IDE, so my question is how any PHP IDEs actually support this feature? If your answer to this question is another question - how any don't support this feature? - then my answer is "none of them". Unless you can prove otherwise, of course. again: it's no rocket science to throw at compile time deprecation warnings years before a final change is planned and so for sloppy legacy code you hav enot more to do than read your error logs after i switched every piece of code i write the last 15 years tpo strict-types, typhe-hints and return-types everywhere while also write a complete autotest suite you can't tell me it costs more time to fix such case warnings by read the log and it would take longer as all your discussions - so why don't you stop it? Just because you disagree with what I have to say does not mean that you can tell me to stop saying it. If you want me to accept that you can have a different opinion then you should extend the same courtesy to me. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
wrote in message news:ba7ed73b-8547-2029-7344-6705a70c6...@rhsoft.net... Am 15.09.2017 um 16:38 schrieb Tony Marston: wrote in message news:8bbcc1fc-0d13-27d4-a04f-0a5ebda4c...@rhsoft.net... Am 15.09.2017 um 11:12 schrieb Tony Marston: I am not asking the world to slow down because I am too lazy to change. I am arguing that case insensitive software has been around for many decades, and for some people to advocate for its removal just because they don't have the brain power to come up with a proper solution for a minor glitch that affects only a small number of languages I find unacceptable. A competent programmer would fix the problem that affects the few without removing a feature that the many are used to and a competent programmer using PHP as programming language would not define a funtion do_something() and write "Do_Something", "do_Something", "DO_something" all over his codebase While that may be "uncool" or even "inconsistent" it does not cause a genuine problem. But you seem to be supporting a change which would be worse than uncool, it would be downright horrific. No human language that I know of allows a word to change its meaning just by changing the case of one or more characters i brought you samples of german where the meanining of the same word changes *dramatically* - "nett zu Vögeln" versus "nett zu vögeln" which goes from "nice to birds" to "nice to fuck" and this standard behaviour was echoed in all the computer systems that I have used since the 1970s. The fact that I can create a function called do_something() and later refer to it as either Do_something(), do_Something() or even Do_SomeThing() may be annoying but it is irrelevant. Do you realise how many problems it would cause if each change in case pointed to a totally different function? only when one is so short-sighted as you act it's not rocket science at compile time throw a error that you are not allowed to define foo() and Foo() in the same software which has no runtime costs and after that you may even have less runtime costs because all the case-insensitive handling can be skipped None of the IDEs that I have used have enforced such a rule, neither have any languages, so it is an artificial rule invented by someone who doesn't now how to provide a proper solution. As I have said in several other posts, the vast majority of the human race has come to accept case-insensitive software, and if you can't implement it then you should step aside and make room for someone who can. and well, for the time of deprecation the compiler code with finally throws errors can issue the warnings with file and line - i assure you that going to fix that warnings takes less time than the whole discussion with you over the last days from several people Would you support anyone who proposed adding a series of functions to PHP core or an extension where every function used exactly the same words but in a different case? see above - just because you assume it's rocket scienece doesn't mean it is You seem to misunderstand the term "rocket science" which means that something is so difficult that it can only be done by a highly trained individual. Something which is NOT rocket science is supposed to be so easy that anyone can do, not just a scientist. People keep telling me that switching between upper and lower case for all character sets in the universe is not 100% simple because of a small number of exceptions. So what? Identify the exceptions and write code which deals with them. If we only wrote deal to deal with the easy stuff there would be no need for highly skilled programmers as anyone could do it. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Rowan Collins" wrote in message news:a7ffce81-74e5-47d0-9ebf-9bdc90e2e...@gmail.com... On 14 September 2017 10:23:48 BST, Tony Marston Would this problem disappear by using UTF8 instead of the Turkish character set? If so then ten no other solution would be required. No, the problem has nothing to do with character sets, but with the actual alphabet that humans in Turkey use, which doesn't follow the same rules as the alphabet that American humans use. Unicode (the standard, not the character set or any of its encodings) has an algorithm / lookup table for "case folding", because "convert everything to lower case" is not a reliable way to produce case insensitive comparisons. Using that correctly world presumably solve this particular problem. The bottom line is that case sensitive comparisons are easier than case insensitive ones. A programmer's job is to write software which makes life easier for his users, not to remove features which his users are used to just because it is "more convenient" for him. While the vast majority of characters in any character set have a one-to-one mapping between upper and lower case, there are exceptions. I have been writing software for several decades, and I have come to know the 80-20 rule which states that 80% of the code is for "normal" circumstances while 20% is for the exceptions, yet coding for the "normal" circumstances takes 20% of the effort while the exceptions require 80%. It is the programmer's job to deal with these exceptions, so to say that it's not going to be done because it is not easy is a very poor excuse. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
wrote in message news:5fe274c1-36de-e650-fd2c-bc4f9caf3...@rhsoft.net... Am 15.09.2017 um 11:25 schrieb Tony Marston: You are missing a third option - Microsoft languages are case-preserving. This is where the IDE ensures that every use of a word is automatically switched to the case used in its original definition. This makes it impossible to use the same word with a different case. a sane IDE for PHP does exactly the same for many many years if you don't insist to change it manually - when you manage that you functions are written all over your codebase with different uppercase/lowercase the problem is looking at you from a mirror every morning How many IDEs out there for PHP? What percentage of them support case preserving? Zend Studio didn't when I used it. PHPEd doesn't. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Lester Caine" wrote in message news:55603872-e832-65ea-25b6-48e01074a...@lsces.co.uk... On 15/09/17 10:02, Tony Marston wrote: Why is it not possible to identify a single upper and lower case variant for every character in every character set? Can't find the right unicode standard page, but https://www.elastic.co/guide/en/elasticsearch/guide/current/case-folding.html sums it up. Try this page: http://unicode.org/faq/casemap_charprop.html Notice that case folding for case insensitive comparisons is relatively easy when compared with case switching. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Lester Caine" wrote in message news:d97cd2e5-bd5b-4c9f-2c20-107560d5a...@lsces.co.uk... On 15/09/17 12:13, Tony Marston wrote: My argument is that far too many people have become used to case insensitive software, and to remove this "feature" for no other reason than the programmers involved would find it "more convenient" to remove the feature altogether rather than make the effort in implementing a proper solution would go down like a ton of bricks with all those users. case-insensitive only works reliably for an ascii character set. This is what the vast majority of PROGRAMMERS expect to see. Even Microsoft 16bit subset of unicode characters can not RELIABLY be upper or lower cased, but add the full unicode set and the conflicts of the number of characters required for one or other conversion explains why a conversion to unicode in the core proved impractical. It may be impractical for lazy programmers, but it is not impossible. While unicode can comfortably deal with one-to-one case mappings, it does provide the means to specify one-to-many case mappings and other special cases. All it needs is for all these special cases to be identified and the "problem" is alleviated. The main point here is that it may be ESSENTIAL to introduce a switch to case sensitive if we are also to convert to full unicode support. The alternative is to restrict the character set back to ascii for all programming operations if case-insensitivity is to be retained. Good idea. If certain characters cause problems when switching case then those characters should be banned. And how many of you have hit the problem of Windows supplying a CamelCase version of a file name when it was entered lower case. I haven't, but I always take the precaution of downshifting all file names in order to avoid problems with that PITA called unix/linux. Since all our web servers are 'non-windows', hitting the idiosyncrasies of these inappropriate case conversions just adds to the fun. That may not the happening these days, but cause major problems at one time! There are still inconsistencies when different browsers render the same HTML, CSS or Javascript differently. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
wrote in message news:8bbcc1fc-0d13-27d4-a04f-0a5ebda4c...@rhsoft.net... Am 15.09.2017 um 11:12 schrieb Tony Marston: I am not asking the world to slow down because I am too lazy to change. I am arguing that case insensitive software has been around for many decades, and for some people to advocate for its removal just because they don't have the brain power to come up with a proper solution for a minor glitch that affects only a small number of languages I find unacceptable. A competent programmer would fix the problem that affects the few without removing a feature that the many are used to and a competent programmer using PHP as programming language would not define a funtion do_something() and write "Do_Something", "do_Something", "DO_something" all over his codebase While that may be "uncool" or even "inconsistent" it does not cause a genuine problem. But you seem to be supporting a change which would be worse than uncool, it would be downright horrific. No human language that I know of allows a word to change its meaning just by changing the case of one or more characters, and this standard behaviour was echoed in all the computer systems that I have used since the 1970s. The fact that I can create a function called do_something() and later refer to it as either Do_something(), do_Something() or even Do_SomeThing() may be annoying but it is irrelevant. Do you realise how many problems it would cause if each change in case pointed to a totally different function? Would you support anyone who proposed adding a series of functions to PHP core or an extension where every function used exactly the same words but in a different case? What will happen in the future if we move away from keyboard input towards speech input? It will not be good enough to simply say a word, you would have to spell it out character by character and specify the case of each character. Do you think that would be a good idea? the problem which makes such a change dramatic is the poor code quality of most projects and as i remeber you even fighted some months ago that a consistent coding style within a project is nothing you care about and that explains how you argue here very well I'm afraid that changing the way I do things just to be "consistent" with others is not a good argument when it ends up being "consistently bad". Weitergeleitete Nachricht Betreff: Re: [PHP-DEV] Class Naming in Core Datum: Mon, 5 Jun 2017 09:14:47 +0100 Von: Tony Marston <tonymars...@hotmail.com> An: internals@lists.php.net Seriously, can you explain in words of one syllable the precise benefits of such a consistency? Can you measure the benefits? Just because some OCD sufferers like consistency is not a good enough reason. I have been programming for over 30 years, and in that time I have had to deal with both snake_case and CamelCase, and while I personally find that snake_case is more readable, especially with names that contain more than 3 or 4 words, I have no trouble reading either. Having a mixture of styles does not cause a problem (except in the minds of OCD sufferers) so IMHO it does not require a solution. Anybody who says that they cannot work with a mixture of naming styles is either a liar or Illiterate. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Alain Williams" wrote in message news:20170915093457.gi8...@phcomp.co.uk... On Fri, Sep 15, 2017 at 09:51:53AM +0100, Tony Marston wrote: >Iike how you map lower -> upper depends on how you encode characters. Then use a single UNICODE character set where every character has both an upper and lower case representation. Problem solved. Not possible - see below. I don't give two hoots what javascript does. Many PHP programmers also write Javascript. Avoiding gratuitous inconsistencies will help them. UNICODE was supposedly invented to deal with all these problems so why doesn't it? Why is it not possible to define an uppercase and lowercase variant of the same character? I don't think that you understand Unicode. Case mapping is not as simple as you seem to think - even in English. For a start there are 3 cases: lower, upper & title. It then gets more complicated. I suggest that you read: http://unicode.org/faq/casemap_charprop.html I have read that article, and while it says that case switching may not be easy it does not say that it is impossible. While most case mappings work on a one-to-one basis it is possible to specify any one-to-any mappings as well as any additional mappings used in case folding for any exceptions. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Alain Williams" wrote in message news:20170915092114.gh8...@phcomp.co.uk... On Fri, Sep 15, 2017 at 10:04:51AM +0100, Tony Marston wrote: >The light bulb was invented by an English man (Joseph Swan), the >television by a >Scott (John Logie Baird); so should the Brits and Scots be the >ones that define >light bulb and TV standards to suit their convenience ? > Don't be silly. Neither light bulbs nor television sets are affected by which case is used in which character set. >>Because the English-speaking world invented both computers and the >>languages used to program them. > >It was a German that invented binary, so my suggestion is to devolve all >future decisions to the Germans. Binary coding is not affected by changes in case so this argument is bogus. I think that both Rowan Collins & I agree on that point. We were commenting on your assertion: >>Because the English-speaking world invented both computers and the >>languages used to program them. > Thus because we are English speaking we do not have a special position to dictate the development of computers and languages -- especially as it affects non-English speakers. You are missing the point. The convention in the whole of the English-speaking world is exactly the same - it has both upper and lower case characters, and the meaning of a word does not change simply because some characters are written in a different case. When a person searches for a word in a dictionary he is not bothered about case. When a person searches for a file in the Windows OS he is not bothered about case. When a person searches for a word inside a file he is not bothered about case. I has seen some search mechanisms which provide the option to make the search case sensitive, but that is an option which has to be turned on - the default is still case insensitive. Can you show me any dictionary in ANY language where the same word has different meanings just by changing the case of one or more characters? Can you show me any language where a single character has multiple alternatives when switching case? By my reckoning case insensitivity has been the default way before computers were invented, and all the software on the early computers was also case insensitive. I have worked on numerous hardware platforms since the 1970s, and they were ALL case insensitive. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Andrey Andreev" wrote in message news:CAPhkiZxdVwiEDOW9XZfcADV+o1UC=sg_pc2nw7nqu1w_gv8...@mail.gmail.com... Hi again, On Fri, Sep 15, 2017 at 12:46 PM, Tony Marston <tonymars...@hotmail.com> wrote: "Andrey Andreev" wrote in message news:CAPhkiZyXgxi-7vWdqA2hxni9SvycuN_pWOOM8un8mUo5qJ=0...@mail.gmail.com... Hi, On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston <tonymars...@hotmail.com> wrote: Far better that that problem is taken away from the file system (which should be clean, robust and fast) and if you want case independence put it up at the application layer. You try telling that to the billions of Windows users who have been used to a case insensitive file system for decades. Not to mention all Microsoft software which is case insensitive. Try to take that away and billions of users will be baying for your blood. Billions? Do we have that statistic available? How many people in the world work with PCs running Microsoft Windows? More than those running alternatives. So you admit that you just made up the number? Can you show me any statistics which prove otherwise? And how many of them have ever encountered case-sensitivity as a concept? None, because they have always used case-insensitive software. And that will not change, regardless of how PHP constants work. Thus, re-inforcing my point - that you're completely off-topic. Do they all manually type-in filenames that they want to open? If so, do they for some reason name their files in all upper-case, but then type in lower-case while opening? When searching for a file in Windows it is not necessary to now what case it was created in. When searching for a word in a file it is not necessary to now what case it was created in. TRy taking that ability away from Windows users and see what reaction you get. 1. Search is a feature that goes way beyond case-sensitivity, and that was not what I was (rhetorically) asking. 2. Unless Windows users search for filenames matching constants declared in PHP code, this is irrelevant. Also, are we Microsoft developers? Are we trying to change Windows? No, but you are suggesting a change from being consistent with Windows to being inconsistent. It *happens* to be consistent; nobody has ever cared about whether it is or not. And I am not suggesting anything. I am simply pointing out the ridiculous false-equivalences you're making. And most importantly: How do everyday Windows users have anything to do with PHP developers? Some people are also Windows users as well as PHP developers, and if those people are told that some of the software which they use is now being switched from being case-insensitive to case-sensitive just because the programmers cannot solve a small problem which only affects a small number of character sets, then those people will not be happy. Case-insensitive software has been around for decades and is regarded by many users as a feature. It that "feature" is broken in a small number of cases then a proper programmer would fix that broken feature and not advocate for its removal just because it is more convenient than developing a fix. You do realize you just went from comparing "billions" and how supposedly an overwhelming majority would be upset, to "some people". And even within that intersection of audiences, you would never be able to convince anybody here, that for some reason John Doe would declare a constant as FOO, but then use it as Foo. I believe I've made my point. Please stop with the non-sense comparisons, and talk about *constants in PHP*. You may think that this issue is limited to constants but others do not. Someone (not me) said that if constants were to be made case sensitive then the rest of the language should follow suit "just to be consistent". Someone else (not me) pointed to a bug regarding case switching when using the Turkish character set. It was suggested that one way to resolve this issue would be to avoid case switching altogether by making everything case sensitive. I suggest you look at Levi Morrison's post dated 14/09/2017 @ 17:02 which said: "For what it is worth the Turkish locale issue is on-topic. If we have case sensitivity and case insensitivity simultaneously in constants and we decide to drop one then the locale issue points towards dropping case insensitivity." My argument is that far too many people have become used to case insensitive software, and to remove this "feature" for no other reason than the programmers involved would find it "more convenient" to remove the feature altogether rather than make the effort in implementing a proper solution would go down like a ton of bricks with all those users. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Andrey Andreev" wrote in message news:CAPhkiZyXgxi-7vWdqA2hxni9SvycuN_pWOOM8un8mUo5qJ=0...@mail.gmail.com... Hi, On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston <tonymars...@hotmail.com> wrote: Far better that that problem is taken away from the file system (which should be clean, robust and fast) and if you want case independence put it up at the application layer. You try telling that to the billions of Windows users who have been used to a case insensitive file system for decades. Not to mention all Microsoft software which is case insensitive. Try to take that away and billions of users will be baying for your blood. Billions? Do we have that statistic available? How many people in the world work with PCs running Microsoft Windows? More than those running alternatives. And how many of them have ever encountered case-sensitivity as a concept? None, because they have always used case-insensitive software. Do they all manually type-in filenames that they want to open? If so, do they for some reason name their files in all upper-case, but then type in lower-case while opening? When searching for a file in Windows it is not necessary to now what case it was created in. When searching for a word in a file it is not necessary to now what case it was created in. TRy taking that ability away from Windows users and see what reaction you get. Also, are we Microsoft developers? Are we trying to change Windows? No, but you are suggesting a change from being consistent with Windows to being inconsistent. And most importantly: How do everyday Windows users have anything to do with PHP developers? Some people are also Windows users as well as PHP developers, and if those people are told that some of the software which they use is now being switched from being case-insensitive to case-sensitive just because the programmers cannot solve a small problem which only affects a small number of character sets, then those people will not be happy. Case-insensitive software has been around for decades and is regarded by many users as a feature. It that "feature" is broken in a small number of cases then a proper programmer would fix that broken feature and not advocate for its removal just because it is more convenient than developing a fix. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
""Christoph M. Becker"" wrote in message news:320b3863-e36b-2ed4-543b-fcbd433b1...@gmx.de... On 14.09.2017 at 23:22, Stanislav Malyshev wrote: [Nikita wrote] +1 on doing this. I can understand having case-insensitive constants, but having both case-sensitive and case-insensitive at the same time is weird and rather useless. I imagine the only reason why this "feature" exists in the first place is to support arbitrary casing for true/false/null, which is better handled by special-casing these particular constants (something we already do for various other reasons). This will simplify the language If we support all case-insensitive constants that are predefined (not sure if any exts do that but we have to support those too if they do) then I don't see a big problem in phasing-out user-defined ones. It seems to me that this would miss the point, namely to introduce some consistency, and to be able to [Nikita continued] reduce implementation complexity on our side and resolve some bugs that are infeasible to fix otherwise. All programming languages that I know of are either case-sensitive or case-insensitive. You are missing a third option - Microsoft languages are case-preserving. This is where the IDE ensures that every use of a word is automatically switched to the case used in its original definition. This makes it impossible to use the same word with a different case. PHP is the sole execption (CMIIW) – and the potential cognitive overhead during programming is hard to justify. Constants are the icing on the cake: they can be either case-insensitive or case-sensitive at the discression of the dev defining the constant. Using an extension which defines case-insensitive constants might raise the following issue: Although the PHP manual says that constants are case-insensitive, it also says that by convention all constants are uppercase. I have been following that convention, so a change to make constants case sensitive instead of insensitive would not bother me. In fact it would not bother me if user-defined constants could only ever be in upper case as that would remove any possible confusion between 'foo' and 'Foo'. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Daniel Morris" wrote in message news:1505397937.4137791.1106049000.16b88...@webmail.messagingengine.com... On Thu, 14 Sep 2017, at 02:48 PM, Tony Marston wrote: Because the English-speaking world invented both computers and the languages used to program them. It was a German that invented binary, so my suggestion is to devolve all future decisions to the Germans. Binary coding is not affected by changes in case so this argument is bogus. On Thu, 14 Sep 2017, at 02:36 PM, Tony Marston wrote: The number of people in the world who use character sets which do not have this problem far outnumber those who use character sets which do have this problem. People without this problem far outnumber the others, so it would not be a good idea to inconvenience the many just to satisfy the few. You are nearly always a minority opinion, the irony of you writing this whilst at the same time asking the world to slow down so that your stubborn fourteen year old framework can catch up beggars belief. I am not asking the world to slow down because I am too lazy to change. I am arguing that case insensitive software has been around for many decades, and for some people to advocate for its removal just because they don't have the brain power to come up with a proper solution for a minor glitch that affects only a small number of languages I find unacceptable. A competent programmer would fix the problem that affects the few without removing a feature that the many are used to. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Alain Williams" wrote in message news:20170914135519.gw8...@phcomp.co.uk... On Thu, Sep 14, 2017 at 02:48:06PM +0100, Tony Marston wrote: "Rowan Collins" wrote in message news:7394e3ce-b05a-474e-8ab5-a651fdd35...@gmail.com... > >On 14 September 2017 13:59:20 BST, Tony Marston ><tonymars...@hotmail.com> wrote: >>Why should the >>English-speaking world be forced to suffer just because some minor >>languages >>cannot handle case folding? > >Have you any idea how arrogant this sounds? Why should "the >English-speaking world" get to make up the rules? What criteria >make something "a minor language"? Who gave you the right to make >such lofty pronouncements? Because the English-speaking world invented both computers and the languages used to program them. The light bulb was invented by an English man (Joseph Swan), the television by a Scott (John Logie Baird); so should the Brits and Scots be the ones that define light bulb and TV standards to suit their convenience ? Don't be silly. Neither light bulbs nor television sets are affected by which case is used in which character set. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Alain Williams" wrote in message news:20170914134603.gs8...@phcomp.co.uk... On Thu, Sep 14, 2017 at 02:36:27PM +0100, Tony Marston wrote: ""Christoph M. Becker"" wrote in message news:98ab178e-b999-7e36-5ff5-7b8c28fe0...@gmx.de... > >On 14.09.2017 at 14:59, Tony Marston wrote: > >>Introducing case sensitivity into what is mostly a case-insensitive >>world just for the convenience of a few programmers I do not consider >>to >>be acceptable. It would cause more problems for far more people than >>the >>insignificant few who insist on using obscure character sets. Why >>should >>the English-speaking world be forced to suffer just because some minor >>languages cannot handle case folding? > >This is not about an "insignificant few who insist on using obscure >character sets", but rather about a language spoken by millions of >people which has to "I" characters, namely dotted and dotless "I". >Rather consistently, the dotless "I"'s lower-case variant is "i", and >the dotted "I"'s lower-case variant is "i". There you go. > The number of people in the world who use character sets which do not have this problem far outnumber those who use character sets which do have this problem. People without this problem far outnumber the others, so it would not be a good idea to inconvenience the many just to satisfy the few. Translation: I do not use these character sets, those who do are not important. Incorrect. The proper question is: How any character sets have this problem? What percentage of the world's computer users are affected by this problem? If this number is quite small then it would be wrong to make the majority suffer just because you don't know how to fix the problem that affects the minority. PHP (& File systems) are best staying away from things like that. Microsoft produces case insensitive software, including file systems, because that is what users are used to. Unix was invented in a laboratory by academics who couldn't develop case insensitive software so they called it a "feature" and not a "bug". Not attempting case folding, and similar, makes it simpler, faster & more robust (not worrying about what sort of 'i' to convert to). It only helps those who do not know what the SHIFT key is for. Why is it not possible to identify a single upper and lower case variant for every character in every character set? -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Alain Williams" wrote in message news:20170914133846.gq8...@phcomp.co.uk... On Thu, Sep 14, 2017 at 02:16:47PM +0100, Tony Marston wrote: A minor detail. Windows followed all the previous OSes which I had used in being case insensitive, which makes unix the odd one out. Besides there are far more computers running Windows than unix, so unixx should not be used as the standard. So you want a return to the horrors of code pages in file systems ? I never said that. Iike how you map lower -> upper depends on how you encode characters. Then use a single UNICODE character set where every character has both an upper and lower case representation. Problem solved. Far better that that problem is taken away from the file system (which should be clean, robust and fast) and if you want case independence put it up at the application layer. You try telling that to the billions of Windows users who have been used to a case insensitive file system for decades. Not to mention all Microsoft software which is case insensitive. Try to take that away and billions of users will be baying for your blood. I vote for making it case sensitive: simpler for the parser; the programmer rapidly learns that it should be 'TRUE' and not 'true' -- job done. This is what Javascript does. I don't give two hoots what javascript does. Many operating systems were case insensitive since your input terminal (eg AR33 Teletype) could only generate one case. But in those days it was simple since you only had one character set: ASCII or EBCDIC (translation of alphabetics between the 2 was easy, some others not so, eg: @"\£#). >But the additional problems that case-insensitive then >introduces may mean that all case-insensitivity has to be removed at >that point? What additional problems? When billions of people are used to living in a case-insensitive world and the only "problems" affect an insignificantly small number in an insignificantly small number of circumstances then the only proper solution is one that solves the problem for the small number without messing it up for the far larger number. That is the sort of mind-set that results in browsers accepting all sort of broken markup and making guesses on what is intended; different browsers make different guesses and render the page differently. The user then blames browser X for getting it wrong rather than the incompetent web developer who can't be bothered to check that their markup is correct. UNICODE was supposedly invented to deal with all these problems so why doesn't it? Why is it not possible to define an uppercase and lowercase variant of the same character? If the problem lies with an incomplete implementation of UNICODE then that is the problem which should be addressed. Any programmer who says that he doesn't have the brain power to provide a proper solution and proposes instead to remove case insensitivity from the entire universe "because it is more convenient" should hang his head in shame. It is the programmer's job to make things easier and more convenient for the user, not for users to accept what is convenient for the programmers to provide. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Rowan Collins" wrote in message news:7394e3ce-b05a-474e-8ab5-a651fdd35...@gmail.com... On 14 September 2017 13:59:20 BST, Tony Marston <tonymars...@hotmail.com> wrote: Why should the English-speaking world be forced to suffer just because some minor languages cannot handle case folding? Have you any idea how arrogant this sounds? Why should "the English-speaking world" get to make up the rules? What criteria make something "a minor language"? Who gave you the right to make such lofty pronouncements? Because the English-speaking world invented both computers and the languages used to program them. The early ASCII character set supported only the English/American languages, and while other languages were supported on an ad hoc basis with specific character sets, the creation of a single UNICODE standard to cover all possible character sets was later created and should be available in all languages. If UNICODE solves all particular issues regarding case-insensitive software, but has yet to be properly implemented in PHP, then the correct response to this problem would be to rectify PHP's implementation. And, please, stop muddling UTF8, a particular way of representing text in binary, with Unicode, the huge and complex standard that attempts to handle fairly these "minor languages" which you dismiss so casually. Or preferably just stop commenting on topics you so obviously don't understand. The terms "UTF8" and "UNICODE" do not mean entirely different things. The page at https://en.wikipedia.org/wiki/UTF-8 speaks of "UTF-8-encoded Unicode", so for may people they are just different sides of the same coin. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
""Christoph M. Becker"" wrote in message news:98ab178e-b999-7e36-5ff5-7b8c28fe0...@gmx.de... On 14.09.2017 at 14:59, Tony Marston wrote: Introducing case sensitivity into what is mostly a case-insensitive world just for the convenience of a few programmers I do not consider to be acceptable. It would cause more problems for far more people than the insignificant few who insist on using obscure character sets. Why should the English-speaking world be forced to suffer just because some minor languages cannot handle case folding? This is not about an "insignificant few who insist on using obscure character sets", but rather about a language spoken by millions of people which has to "I" characters, namely dotted and dotless "I". Rather consistently, the dotless "I"'s lower-case variant is "i", and the dotted "I"'s lower-case variant is "i". There you go. The number of people in the world who use character sets which do not have this problem far outnumber those who use character sets which do have this problem. People without this problem far outnumber the others, so it would not be a good idea to inconvenience the many just to satisfy the few. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Lester Caine" wrote in message news:20b8b6fa-ec81-eba9-d33b-b54b815e9...@lsces.co.uk... On 14/09/17 10:20, Tony Marston wrote: Then unix came along and FUBAR'd everything. Any advantages of case sensitive systems are ALWAYS outweighed by their disadvantages. Unix predates Windows ... A minor detail. Windows followed all the previous OSes which I had used in being case insensitive, which makes unix the odd one out. Besides there are far more computers running Windows than unix, so unixx should not be used as the standard. the use of such breaks as having spaces in file names came from that development in addition to the line ending. The RTTY machines needed a carriage return step followed by a line feed which is why that was two steps initially. Not needed these days, but still embeded from the early days. I also saw LF and CR being used independently in a driver for a daisywheel printer in the 1970s. The fact that both CR and LF are not needed these days should have been addressed by a common solution used by all OSes, and not each OS using a different solution. UTF8 introduces a level of complexity and can be used used in many places in PHP, but it does seem that there is no drive these days to make the core a clean UTF8 environment. This should perhaps be addressed again for PHP8? If UTF8 solves the problem, but has yet to be properly implemented in PHP, then the PHP implementation should be addressed. But the additional problems that case-insensitive then introduces may mean that all case-insensitivity has to be removed at that point? What additional problems? When billions of people are used to living in a case-insensitive world and the only "problems" affect an insignificantly small number in an insignificantly small number of circumstances then the only proper solution is one that solves the problem for the small number without messing it up for the far larger number. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Daniel Morris" wrote in message news:1505382004.4078127.1105791680.3a06c...@webmail.messagingengine.com... On Thu, 14 Sep 2017, at 10:20 AM, Tony Marston wrote: If the first programming languages in the first computers were case insensitive, then that should be the standard. Those who introduced case sensitive languages at a later date should be forced to justify that decision. If the first vehicles had two wheels, then that should be the standard. Those who introduced cars with four wheels should be forced to justify that decision. If the first television was black and white, then that should be the standard. Those who introduced televisions with colour should be forced to justify that decision. If the first living organisms had single cells, then that should be the standard. Evolution should be forced to justify the decision to move to multiple cells. If light exists as a wave, then that should be the standard. When an observer collapses the wave function, then they should be forced to justify that decision. -- Daniel Morris dan...@honestempire.com You are being deliberately awkward. While things can progress, change, improve and be added to over time, I can see no justification for removing a facility or capability just for the convenience of a miniscule number of developers. Just because the first Ford motor cars were black is no justification for saying that all cars should be black. The idea that all cars should have their ability to steer around bends be removed just because the car makers find it easier to build cars that can only run in straight lines would be just plain nonsense. Introducing case sensitivity into what is mostly a case-insensitive world just for the convenience of a few programmers I do not consider to be acceptable. It would cause more problems for far more people than the insignificant few who insist on using obscure character sets. Why should the English-speaking world be forced to suffer just because some minor languages cannot handle case folding? If the problem has already been solved with UTF8 then no other solution should be required. If the support for UTF8 needs to be enhanced in PHP then enhance it. Do not remove case-insensitive software just because it is "convenient". As was said in a Star Trek movie - the needs of the many outweigh the needs of the few. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
""Tony Marston"" wrote in message news:09.43.19300.8e659...@pb1.pair.com... "Levi Morrison" wrote in message news:cafmt4nrc43y-nl_v85qt7jgv1ohm0y4kexhb4e3mi1ejhj0...@mail.gmail.com... On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston <tonymars...@hotmail.com> wrote: People who think that case sensitive software is cool are deluding themselves. When I started working on mainframe computers (UNIVAC and IBM) in the early 1970s everything was case-insensitive. This was only changed by people who did not understand the ramifications of their choice. Actually there are concrete bugs caused by case insensitivity. For one example, here is our own bugs.ph p.net report about a Turkish locale issue: https://bugs.php.net/bug.php?id=18556 The short summary of the issue is that when capital `I`, the ninth letter of the English alphabet, is lowercased in the Turkish locales it does not become the same `i` as it does in English but a different i that is not considered equal. Thus classes such as `Iterator` are not found in the Turkish locales. Note that this bug was fixed, and then there was a regression that lasted until PHP 5.5. There are other case insensitivity bugs but this Turkish one is the poster child and if you search around you can find many examples of it. Case sensitivity is thus *a correctness issue* and not a "cool"ness, personal preference, performance, or some other type of issue. I argue correctness and maintenance issues are the most important and thus if we change sensitivity of *any* type of symbol it should go in the direction of being case sensitive. Someone can disagree on what they value but people who think case insensitivity is not a correctness issue "are deluding themselves". Levi Morrison I'm sorry, but errors in translation from one character set to another are insignificant when compared with the much larger problem of the same word having diferent meanings depending on case. In the English language "info" is the same as "Info" is the same as "INFO" is the same as "iNFO" is the same as "iNfO" and so on. If the problem is that an English word cannot be recognised as the same word regardless of case when switching to a non-English character set then the issue is with switching to a non-English character set. Introducing case sensitivity just for this minor bug would create more issues than it would solve, so this bug should be solved using a different technique . Would this problem disappear by using UTF8 instead of the Turkish character set? If so then ten no other solution would be required. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Sara Golemon" wrote in message news:CAESVnVp6OKB64WuO9iKEP=l9-qrrfjs+kcoekykulruff-r...@mail.gmail.com... On Wed, Sep 13, 2017 at 8:59 AM, Tony Marston <tonymars...@hotmail.com> wrote: People who think that case sensitive software is cool are deluding themselves. When I started working on mainframe computers (UNIVAC and IBM) in the early 1970s everything was case-insensitive. This was only changed by people who did not understand the ramifications of their choice. Yeah, decades of C/C++/Java developers are so dumb, like... fer reals. Friggin' script kiddies, the lot of 'em. -Sara If the first programming languages in the first computers were case insensitive, then that should be the standard. Those who introduced case sensitive languages at a later date should be forced to justify that decision. It is the same for file systems - all the pre-unix systems I worked on were case insensitive, as have been all versions of Microsoft Windows. Then unix came along and FUBAR'd everything. Any advantages of case sensitive systems are ALWAYS outweighed by their disadvantages. A similar cockup occurred with line endings. The original convention on teletypes was to use line-feed (LF) and carriage-return (CR) together which have separate meanings and could either be used independently or together. Then some clueless newbies came along and changed everything so that some OSes use just LF while others use just just CR. This now causes problems when transferring files from one OS to another. This shows what happens when "friggin' script kiddies" (your words, not mine) come up with an idea without understanding what the current convention is. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Ryan Pallas" wrote in message news:caobuzdtmhxq285hwmc3x9th2rj9d7ty3vnhnpcbzdceppch...@mail.gmail.com... On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston <tonymars...@hotmail.com> wrote: You seem to forget that autoloading is an option, not a requirement. I don't use autoloading in my 14 year old framework for several reasons: - An autoloader did not exist when I created my framework. - I built an alternative mechanism into my framework, so I don't need an autoloader. - I don't like the way autoloaders work - all my class names are in snake case (lowercase with underscore separators) and the autoloader converts '_' into '/' thus producing a file path which does not exist. I must be missing something, there is no autoloader shipped with PHP. You have to define your own and register it. You can choose to change _ into / within your autoloader, but that is entirely preference and not specifically part of autoloading. For example, here's my autoloader which does no such symbol replacement https://pastebin.com/rQRrXzCa Then it must have been the project I was working on which used a combination of Codeigniter, Composer and PHPUnit. There was definitely something which translated a class name from "foo_bar_snafu" into "foo/bar/snafu". It's no wonder that I stopped using it. -- Tony Marston http://www.tonymarston.net http://www.radicore.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Levi Morrison" wrote in message news:cafmt4nrc43y-nl_v85qt7jgv1ohm0y4kexhb4e3mi1ejhj0...@mail.gmail.com... On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston <tonymars...@hotmail.com> wrote: People who think that case sensitive software is cool are deluding themselves. When I started working on mainframe computers (UNIVAC and IBM) in the early 1970s everything was case-insensitive. This was only changed by people who did not understand the ramifications of their choice. Actually there are concrete bugs caused by case insensitivity. For one example, here is our own bugs.ph p.net report about a Turkish locale issue: https://bugs.php.net/bug.php?id=18556 The short summary of the issue is that when capital `I`, the ninth letter of the English alphabet, is lowercased in the Turkish locales it does not become the same `i` as it does in English but a different i that is not considered equal. Thus classes such as `Iterator` are not found in the Turkish locales. Note that this bug was fixed, and then there was a regression that lasted until PHP 5.5. There are other case insensitivity bugs but this Turkish one is the poster child and if you search around you can find many examples of it. Case sensitivity is thus *a correctness issue* and not a "cool"ness, personal preference, performance, or some other type of issue. I argue correctness and maintenance issues are the most important and thus if we change sensitivity of *any* type of symbol it should go in the direction of being case sensitive. Someone can disagree on what they value but people who think case insensitivity is not a correctness issue "are deluding themselves". Levi Morrison I'm sorry, but errors in translation from one character set to another are insignificant when compared with the much larger problem of the same word having diferent meanings depending on case. In the English language "info" is the same as "Info" is the same as "INFO" is the same as "iNFO" is the same as "iNfO" and so on. If the problem is that an English word cannot be recognised as the same word regardless of case when switching to a non-English character set then the issue is with switching to a non-English character set. Introducing case sensitivity just for this minor bug would create more issues than it would solve, so this bug should be solved using a different technique . -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Sara Golemon" wrote in message news:CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=u_f3gd87rm...@mail.gmail.com... On Tue, Sep 12, 2017 at 5:02 AM, Christoph M. Becker <cmbecke...@gmx.de> wrote: Even if these issues could be resolved, I still think allowing both case-sensitive and case-insensitive constant identifiers does more harm than good. +0.1 to removing case-insensitive constants, though we'd need to define both "null" and "NULL" (similar for true and false) since there's little consensus on which version of these constants get used from project to project. Also: While deprecating for 7.3 is fine, I'd favor waiting for 8.0 for full removal. As to François' suggestion to make the whole language case-sensitive? Yeesh, that feels like a much more aggressive movement. In the case of constants they very nearly are case-sensitive only since, as you point out, common practice is to not pass true for that third parameter, and to prefer `const` over `define` anyway. Identifiers are another matter since they're insensitive by default. In the case of classnames I could almost get on board since autoloading standards have pushed users naturally in the direction of respecting case sensitive as a coding standard. I don't feel as though that's true of functions or of projects where autoloaders aren't used (not a small number). You seem to forget that autoloading is an option, not a requirement. I don't use autoloading in my 14 year old framework for several reasons: - An autoloader did not exist when I created my framework. - I built an alternative mechanism into my framework, so I don't need an autoloader. - I don't like the way autoloaders work - all my class names are in snake case (lowercase with underscore separators) and the autoloader converts '_' into '/' thus producing a file path which does not exist. By convention I always use uppercase for constants which makes them instantly recognisable in my code as all other names are either completely lowercase or mixed case. Making constants case sensitive instead of insensitive would not affect me. However, I would be totally against switching the rest of the language to be case sensitive for the following reasons: - It would be a huge BC break no little or no benefit. - It would allow developers to shoot themselves in the foot by having different functions with the same name but different mixtures of case, so that foo(), Foo() FOO() and fOO() would be treated as different functions. - if people move from keyboard input to speech recognition, then simply speaking a name would not work - you would have to spell it out character by character, and specify either upper or lowercase for each character. People who think that case sensitive software is cool are deluding themselves. When I started working on mainframe computers (UNIVAC and IBM) in the early 1970s everything was case-insensitive. This was only changed by people who did not understand the ramifications of their choice. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Match expression
wrote in message news:7cd2884a-6606-4c3f-8f95-776fd277878b@Spark... Hi Tony … you sometimes forget to insert a break statement then that is your fault. Any bug in your source code is ultimately your fault. But as mentioned before human error is inevitable. You can make it easier for your users to make less mistakes though. Other languages (e.g. Rust or Swift) have implicit breaks in their switch statements. This has been done for a reason, I wouldn’t call this a non-issue. The problem with implicit breaks is that it makes it impossible to group several conditions with a single break. My previous language use implicit breaks, and this problem really annoyed me. With PHP I have more control, and the fact that I have to insert explicit breaks I do not see as an inconvenience. Millions of other programmers have no problem with the switch statement It’s all they know. They don’t complain about null pointers even though it’s inventor calls it his billion-dollar mistake. The customer rarely knows what he truly needs. They know what they want to achieve, and they have to know which language features are available to help them meet their objectives. The fact that some language features have turned out to be a big mistake is purely the fault of the people who introduced those features. Some programmers complain about some languages features even though they are useful features which work as advertised as are not deemed to be a mistake - take yourself for example who is now complaining about issues with the switch statement. If what you want to achieve can be done better with a series of if/elseif statements than the switch statement, then why can't you use if/elseif instead of making the language more complicated? -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Match expression
wrote in message news:eb28362c-4f8f-45df-bbf0-582e8ad2b8af@Spark... Hi everybody! Has this idea been discussed before? I find myself writing switch statements in PHP quite rarely. This has a few reasons: 1. It doesn’t have a "strict_types” version 2. It is quite verbose (lots of breaks) 3. It is a statement rather than an expression Often, if / elseif statements turn out to be shorter, safer and easier to read than the switch statement. What I’d really love is something like a match expression: If there are circumstances where a series of if / elseif statements turn out to be shorter, safer and easier to read than a switch statement, then the intelligent thing to do would be to use if / elseif statements instead of trying to make the switch statement more complicated. If your problem with the switch statement is that you sometimes forget to insert a break statement then that is your fault. Try to use the language features as they were intended to be used and not how you would personally like to use them. Millions of other programmers have no problem with the switch statement, and they would not be pleased to have it changed just to deal with your perceived problem with it. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A validator module for PHP7
pe you understand my intentions and accept the feature in core. Feature for core should be in core. IMO. The filter functions are already in core. How these functions are used is down to userland code. 1) Primary validation, where each field is validated against the column specifications in the database to ensure that the value can be written to that column without causing an error. For example this checks that a number is a number, a data is a date, a required field is not null, etc. 2) Secondary validation, where additional validation/business rules are applied such as comparing the values from several fields. For example, to check that START_DATE is not later than END_DATE. Validation rules for input, logic and database may differ. Suppose you validate "user comment" data. Input:0 -10240 bytes - Input might have to allow larger size than logic. i.e. lacks client side validation. Logic: 10 - 1024 bytes - Logic may require smaller range as correct data. Database: 0 - 102400 bytes - Database may allow much larger size for future extension. Under ideal situation, all of these may be the same but they are not in real world. I wouldn't aim to consolidate all validations, but I would like to avoid unnecessary incompatibilities so that different validations can cooperate if it is possible. What exactly are these "unnecessary incompatibilities"? I'm very interested in PDO level validation because SQLite3 could be very dangerous. Anything which is misused can be dangerous. It is almost impossible to provide a function and prevent stupid people from misusing it. (i.e. Type affinity allows store strings in int/float/date/etc) It may be useful if PDO can simply use "validate" module's rule or API. BTW, Input validation should only validate format(used char, length, range, encoding) if we follow single responsibility principle. Logical correctness is upto logic. i.e. Model in MVC. Anyway, goal is providing usable basic validator for core features and security. If you wish to improve the filter functions ten go ahead. Anything more than this would be a step too far. Required trade offs may be allowed. Do not waste time by trying to add into core what should be done in userland code. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A validator module for PHP7
"Dan Ackroyd" wrote in message news:ca+kxmusl1kew60s7dfjb06+r2q3rc1ueewu1jap78fy65aj...@mail.gmail.com... On 6 September 2017 at 13:31, Rowan Collins <rowan.coll...@gmail.com> wrote: I'm going to assume that the code you posted was something of a straw man, and you're not actually advocating people copy 20 lines of code for every variable they want to validate. You assume wrong. No it's not, and yes I am. I can point a junior developer at the function and they can understand it. If I ask that junior developer to add an extra rule that doesn't currently exist, they can without having to dive into a full library of validation code. If I need to modify the validation based on extra input (e.g whether the user has already made several purchases, or whether they're a brand new signup), it's trivial to add that to the function. This is one of the times where code re-use through copying and pasting is far superior to trying to make stuff "simple" by going through an array based 'specification'. It turns out that that doesn't save much time to begin with, and then becomes hard to manage when your requirements get more complication. As a person who has been developing database applications for several decades and with PHP since 2003 I'd like to chip in with my 2 cent's worth. Firstly I agree with Dan's statement: This type of library should be done in PHP, not in C. Secondly, there is absolutely no way that you can construct a standard library which can execute all the possible validation rules that may exist. In my not inconsiderable experience there are two types of validation: 1) Primary validation, where each field is validated against the column specifications in the database to ensure that the value can be written to that column without causing an error. For example this checks that a number is a number, a data is a date, a required field is not null, etc. 2) Secondary validation, where additional validation/business rules are applied such as comparing the values from several fields. For example, to check that START_DATE is not later tyhan END_DATE. Primary validation is easy to automate. I have a separate class for each database table, and each class contains an array of field specifications. This is never written by hand as it is produced by my Data Dictionary which imports data from the database schema then exports that data in the form of table class files and table structure files. When data is sent to a table class for inserting or updating in the database I have written a standard validation procedure which takes two arrays - an array of field=value pairs and a array of field=specifications - and then checks that each field conforms to its specifications. This validation procedure is built into the framework and executed automatically before any data is written to the database, so requires absolutely no intervention by the developer. Secondary validation cannot be automated, so it requires additional code to be inserted into the relevant validation method. There are several of these which are defined in my abstract table class and which are executed automatically at a predetermined point in the processing cycle. These methods are defined in the abstract class but are empty. If specific code is required then the empty class can be copied from the abstract class to the concrete class where it can be filled with the necessary code. If there are any developers out there who are still writing code to perform primary validation then you may learn something from my implementation. If there are any developers out there who think that secondary validation can be automated I can only say "dream on". -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Allow default value in list() syntax
"Andreas Hennings" wrote in message
news:CAH0Uv3HQK5wjcd_-9GynMw34H78ZTv09q9bc=yZ10JBbeT=v...@mail.gmail.com...
On Fri, Aug 11, 2017 at 12:01 AM, Devnuhl Unnamed <devn...@gmail.com>
wrote:
Would isset($suffix) not suffice here?
You mean like so?
list($prefix, $suffix) = explode(':', 'string_without_suffix');
if (!isset($suffix)) {
..
}
The isset() is too late here, because the list() will already cause an
error.
Other concerns fall around list() already being a difficult thing for
people to understand
I agree.
I fail to understand what is difficult about it.
The point is that other people have difficulty understanding what is
supposed to be a simple feature which is now being expanded to include more
options which change its behaviour.
And "destructuring" is a common concept in programming languages.
https://www.startpage.com/do/search
?query=destructuring=web=chrome=english
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment
The following already works in Javascript:
[a, b, c, d = 'else'] = ['aa', 'bb', 'cc'];
I just tried it in my Chromium console.
That fact that something like this exists in another language is no reason
to add it to PHP.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.net website
"Niklas Keller" wrote in message news:canuqdcjb9uy8jtmmp43bqaw_9xjnombren1zoqh1lubtfo4...@mail.gmail.com... On Wed, Jul 19, 2017 at 1:07 PM, Mathias Grimm <mathiasgr...@gmail.com> wrote: > I was briefly asking Sara about it and as she pointed out it is likely > a > big project but I think we can do something about it. > One thing I should have mentioned on twitter was: https://wiki.php.net/web/mirror That'll get you a locally running web-php instance though it's not ideal for iterative development against the git repo without some massaging. As to the actual hosts: There are (I believe) two hosts actually administered by @php.net folk: us1.php.net and us2.php.net, others (AIUI) are run by third parties and not under our control. The PHP version on these hosts is, comically, not the lastest-and-greatest. I'm fairly confident it's not even consistently 7.0+ so whatever you write needs to take that into account (particularly given the status of third-party mirrors). We should really change that and fully move to HTTPS. Regards, Niklas Why on earth should you need to use HTTPS for a website that does not deal with personal information? Nothing on that website can possibly be classed as "sensitive" so what would be the point? -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array coalesce operator concept
"David Rodrigues" wrote in message news:caesg9x2ecg62i7z_nu11kqr7yvbkmucd3mxgt78ulampfx-...@mail.gmail.com... The idea is good, but I don't know if it is more clear than an 'if()' I think that this proposal is totally ridiculous and should be shot down in flames. My reasoning is as follows: 1) There should be a rule that anything which can be achieved with 5 lines or less in userland code should be automatically excluded from becoming a change to the language. The cost of changing the language in order to get around the laziness of a small number of users versus the "benefit" of making the language more complicated for the rest of us, as well as adding to the maintenance burden is simply not worth it. 2) Proposals such as this violate the first rule of good programming which is to provide code which is readable and therefore understandable by others, and therefore maintainable. I don't know about you, but I find it much easier to read words than symbols. The idea that the code "if (is_array($foo))" is too verbose and should be replaced with a shorthand symbol is just too ridiculous for word. If any more of these shortcuts is implemented then I'm afraid that code will look too much like a bunch of hieroglyphics and become far less readable. Just my 2 cents worth. -- Tony Marston Em 11 de jul de 2017 12:15 PM, "Mark Shust" <m...@shust.com> escreveu: Hello, I wanted to garnish feedback on a RFC proposal. This is just a concept at this point, and is inspired by the null coalesce operator. Code will error if a non-array value is passed through a looping feature. For example, this code: PHP Warning: Invalid argument supplied for foreach() in test.php on line 3 To prevent this, the logical solution is to wrap this in an is_array check: sugar/improvement, this can be shorthand for executing the loop instead of wrapping the block within an is_array check: -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Naming in Core
"Rowan Collins" wrote in message news:3351770b-c53e-4062-a91a-d3aa7439f...@gmail.com... On 5 June 2017 09:14:47 BST, Tony Marston <tonymars...@hotmail.com> wrote: Seriously, can you explain in words of one syllable the precise benefits of such a consistency? I will try: - When we write code, we need to know how to spell the names of things. If the things all have names that look the same, it is less hard for us to guess what the name is. This means we take less time to learn the names, and get less things wrong. Words and abbreviations are spelled the same whether you use snake_case or CamelCase, the only difference is how you show the boundary between one word and the next. Studies have shown that snake_case is more readable than CamelCase. - Our brains are made to spot when things are the same, and when things are not the same. When one thing is not like the things near it, we think "why is that?" This slows us down. Seeing a name written in snake_case does not slow you down. In normal writing there is a space between each word, but as names in software cannot have embedded spaces. This is why underscores are used, and this is infinitely more readable than replacing spaces with a capital letter. - When we get things wrong, we need to find out what we did wrong. If one way to write a name is wrong, we can spot when we wrote it that way, and know that it is wrong. Writing a name wrong has nothing to do with the difference between snake_case and CamelCase. My IDE will show me existing names that match what I am typing as soon as I start typing, so I can easily pick the name that I want. - If we make two things that mean the same thing, but do not look the same, we might not spot that we wrote a third thing that does not mean the same thing. If you try to instantiate a class that does not exist, or call a method/function which does not exist, then you will soon know about it. Using snake_case instead of CamelCase does not invite more errors. I think there are more things that make it good to have names that look the same, but I hope this helps for now. The only universally accepted "rule" for names is that they be unique and convey proper meaning. In proper languages all names are case-insensitive as the ability to write the same name with the exact same spelling but different case is simply inviting disaster. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Naming in Core
wrote in message news:a6f250ec-c72a-0522-cbf0-2c7b29ed9...@rhsoft.net... Am 05.06.2017 um 10:14 schrieb Tony Marston: wrote in message news:3cfc0130-e530-64ed-36e8-372b04481...@rhsoft.net... Am 04.06.2017 um 11:10 schrieb Tony Marston: If there was never a standard to begin with then there should be proper justification for introducing one now, and I'm afraid that "to be consistent" is not a valid argument. What problems are caused by this inconsistency? What is the cost, both in core developer time and application developer time, to change it? If the benefits are smaller than the costs then can the change actually be justified? seriously, if you don't understand the obvious benefits of consistency when a lot of different people have to deal with source code over a long period of time likely the discussion with you is pointless and just wasted time for everybody involved Seriously, can you explain in words of one syllable the precise benefits of such a consistency? Can you measure the benefits? Just because some OCD sufferers like consistency is not a good enough reason. I have been programming for over 30 years, and in that time I have had to deal with both snake_case and CamelCase, and while I personally find that snake_case is more readable, especially with names that contain more than 3 or 4 words, I have no trouble reading either. Having a mixture of styles does not cause a problem (except in the minds of OCD sufferers) so IMHO it does not require a solution. Anybody who says that they cannot work with a mixture of naming styles is either a liar or Illiterate it feels like talking with a blind guy about colors who said "cannot"? i can mess up my living room and life still goes on but i won't i can live without taking a shower over weeks but i won't i could work with someone which has a terrible coding style but i won't Anybody whose says that using snake_case instead of CamelCase for names causes any sort of "problem" is exaggerating. I have been using a mixture of naming conventions for several decades, the only "rule" being that each name must convey a proper meaning, and I have never had a problem. This matter does not cause a genuine problem, so it does not need any sort of solution. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Naming in Core
wrote in message news:3cfc0130-e530-64ed-36e8-372b04481...@rhsoft.net... Am 04.06.2017 um 11:10 schrieb Tony Marston: If there was never a standard to begin with then there should be proper justification for introducing one now, and I'm afraid that "to be consistent" is not a valid argument. What problems are caused by this inconsistency? What is the cost, both in core developer time and application developer time, to change it? If the benefits are smaller than the costs then can the change actually be justified? seriously, if you don't understand the obvious benefits of consistency when a lot of different people have to deal with source code over a long period of time likely the discussion with you is pointless and just wasted time for everybody involved Seriously, can you explain in words of one syllable the precise benefits of such a consistency? Can you measure the benefits? Just because some OCD sufferers like consistency is not a good enough reason. I have been programming for over 30 years, and in that time I have had to deal with both snake_case and CamelCase, and while I personally find that snake_case is more readable, especially with names that contain more than 3 or 4 words, I have no trouble reading either. Having a mixture of styles does not cause a problem (except in the minds of OCD sufferers) so IMHO it does not require a solution. Anybody who says that they cannot work with a mixture of naming styles is either a liar or Illiterate. in the time you wasted with your mails i typically cleanup inconsistency here and there in a project with 25 lines of code which dates back to 2003 to make my own life as core-developer and everybody elses easier There are some changes which cause a lot more effort to be wasted. I remember that the move from PHP4 to PHP5 was made more difficult than it should have been simply because someone decided that the method/function names for the XSL extension should be converted from snake_case to CamelCase just to be "consistent". The proposed change is purely cosmetic and has absolutely no effect on functionality, so what is the point? There are costs but no benefits, so can the change really be justified? -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Naming in Core
""Steven Hilder"" wrote in message news:op.y09fz0b4twp9n2@charlie... Tony, On 30 May 2017 11:21:38 +0300, Tony Marston <tonymars...@hotmail.com> wrote: they should not be forced to change just because some nerd has made a unilateral decision which is way above his pay grade On 30 May 2017 16:18:21 +0300, Tony Marston <tonymars...@hotmail.com> wrote: just because someone that there should now be a standard. Who gives this "someone" the right to demand a change in the name of consistency On 31 May 2017 12:19:59 +0300, Tony Marston <tonymars...@hotmail.com> wrote: IMHO it is wrong for someone new to the project to demand that there be a standard, one of his choosing, and that all existing code be modified to conform to that standard. On 02 Jun 2017 10:56:57 +0300, Tony Marston <tonymars...@hotmail.com> wrote: I object to some young nerd arriving on the scene and proclaiming to the world that he has decided to change the "standards" and demand that everyone follow. Who gave him the right to change the standards?the On 03 Jun 2017 11:10:39 +0300, Tony Marston <tonymars...@hotmail.com> wrote: That strikes me as being dictatorial and authoritarian You're correct that nothing gives any one person the right to demand a change to naming conventions or any other element of PHP - hence why nobody here is making any such demands or proclamations. However, what you seem not to recognise is that any person has the right to suggest or campaign for such a change, regardless of their age, experience level, pay grade, nerdiness or severity of OCD. To imply otherwise is offensive. The purpose both of debating suggestions on this list and carrying out the RFC process is to determine if the internals community can reach a consensus on a proposal's viability for inclusion in PHP. Only if and when consensus is achieved will the change be implemented. There are no unilateral decisions. To imply otherwise is to fundamentally misunderstand how open-source collaboration works. Furthermore, there is absolutely no prerequisite that a standard must have been in place since the project's inception for a proposal to be valid. If there was never a standard to begin with then there should be proper justification for introducing one now, and I'm afraid that "to be consistent" is not a valid argument. What problems are caused by this inconsistency? What is the cost, both in core developer time and application developer time, to change it? If the benefits are smaller than the costs then can the change actually be justified? None of what I have written above should be news to you, and Rowan has already clarified that you are not being forced or even asked to change any of your own code. So why do you persist? Because I have been using PHP since 2002, and have been following this group shortly after, and there is one pattern I have seen over and over again. After a change has been made in PHP core to enforce a "standard" for nothing more than "to be consistent", some bright spark will try to enforce it on the greater PHP community. After all, it is the "standard" right? Why should there be one standard for the core developers and another standard for the application developers? Sure that's inconsistent, and as such it must be a "bad thing". I disapprove of any change to the language which is purely cosmetic and not an improvement in functionality. The words that I use to express my disapproval are an indicator of my level of disapproval. When I describe the supporters of this RFC as nit-picking, anal-retentive OCD sufferers you may regard that as derogatory but it is far from being abusive. I am simply pointing out that supporters of this RFC are spending too much time on irrelevant and trivial details which will not improve the language in any way whatsoever. My words may annoy you, but I am just as annoyed at RFCs like this one. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Naming in Core
"Dan Ackroyd" wrote in message news:ca+kxmuromvy6vb0ykd6ejqu8askxro2x6f9y5i9+cxfjsj-...@mail.gmail.com... On 29 May 2017 at 23:13, Fleshgrinder <p...@fleshgrinder.com> wrote: Hey guys! People are complaining over at Reddit [1] While the "STD" is slightly humorous, it is unneeded verbosity, and will lead to pointless arguments in the future of whether other features in the future should catch the STD name, or whether they should be directly under PHP. I would recommend not using it. I don't care about case, though there may be a slight argument that upper-casing initialisations is the 'standard' in PHP core. It can only be the "standard" if it has been documented as such and everyone follows it. If it was not documented as such from the start of the project then it does not qualify. It may have become the most commonly used in a selection of alternatives, but that does not give anyone the right to now say that it has become the standard and should be enforced. That strikes me as being dictatorial and authoritarian, as well as requiring large amounts of effort without offering any tangible benefits. I'm "consistency" is not a valid benefit in my book. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Naming in Core
"Dan Ackroyd" wrote in message news:ca+kxmutdqv4pg7yqq10p2vfdu4cyv0cwe1d7xwbvcio44pt...@mail.gmail.com... On 2 June 2017 at 08:56, Tony Marston <tonymars...@hotmail.com> wrote: I object to some young nerd arriving on the scene Please don't make derogatory comments. A mildly derogatory comment which indicates the low esteem in which I hold people with such thoughts is not the same as personal abuse, so stop trying to make a mountain out of a molehill. Also, this tangent on naming conventions in general is off-topic to this thread. Please stay on topic. How can it be off-topic to talk about naming conventions in a thread with the title "class naming"? -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Naming in Core
"Rowan Collins" wrote in message news:41f2b884-5db7-4691-b540-97b0daeaa...@gmail.com... On 1 June 2017 10:16:16 BST, Tony Marston <tonymars...@hotmail.com> wrote: "Rowan Collins" wrote in message news:cef783bb-8e1f-4a20-9cc6-1364a122b...@gmail.com... On 31 May 2017 10:26:06 BST, Tony Marston <tonymars...@hotmail.com> wrote: wrote in message news:86dba466-a764-522b-6990-39fd7668a...@fleshgrinder.com... I should point out that snake_case was the universal standard decades before some people switched to CamelCase. [citation needed] My first job in computing was with a UNIVAC 1108 mainframe in the 1970s. This used a 6-bit character instead of an 8-bit byte, which meant that it could support upper case characters, but not lower case. Where a name was comprised of several words an underscore separator was used, as in "end_of_file". Fascinating, but doesn't make it "universal", or frankly have anything to do with how we write code 40 years later. Some people have been writing code for decades, and those practices which they learnt at the start of their careers tend to stick. As one of these "old timers" I object to some young nerd arriving on the scene and proclaiming to the world that he has decided to change the "standards" and demand that everyone follow. Who gave him the right to change the standards? Are there standards that he can actually change? Bearing in mind that there is no such thing as a universal naming standard (apart from names being readable and meaningful) what gives this nerd the right to say "you cannot use snake_case any more, everything has to be CamelCase"? That was only because some software could not handle long names, but could handle both upper and lower case, so an upper case character was used instead of an underscore. [citation needed] Try reading https://en.wikipedia.org/wiki/Naming_convention_(programming)#Length_of_identifiers Mentions absolutely nothing about the origins of CamelCase, which a quick search suggests is somewhat unknown. One theory is apparently environments whose character sets had replaced underscore with a left-arrow assignment operator. Which, again, is fascinating but is as irrelevant to designing modern languages as the origins of the word "beef" is to ordering a cheeseburger. Some studies have shown that that most people find it easier to read compound names which use the underscore separator. Look at the following: https://en.wikipedia.org/wiki/Camel_case#Readability_studies https://en.wikipedia.org/wiki/Snake_case (first paragraph) This, however, is at least tangentially relevant to the original topic, since it shows some reasons to pick one convention over the other. Different groups of people follow different naming conventions simply because there is no universally accepted standard. The convention that they follow is usually down to personal choice, and if their convention produces readable and meaningful names it is not unreasonable for them to object to being told that they must now follow somebody else's personal choice for no good reason other than to be "consistent". If the effort of changing to be "consistent" has costs but no tangible benefits, then in my book it cannot be justified and is not worth the effort. Even more relevant would be studies testing the advantages of having a convention at all, which I would expect to include increased efficiency and reduced mistakes because it's easier to remember a list of items that follow a fixed pattern. If there is no such thing as a single convention when it comes to naming functions, classes and methods, then what is the benefit of trying to enforce one? All you will do is annoy those people who are forced to change, especially when it means taking a name in a readable format and changing it to a less-readable format. Provided that the names used are readable and meaningful, what exactly is the benefit of enforcing one naming convention over another? Any follower of CamelCase who says that he cannot read names written in snake_case is either a liar or illiterate. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Naming in Core
"Rowan Collins" wrote in message news:cef783bb-8e1f-4a20-9cc6-1364a122b...@gmail.com... On 31 May 2017 10:26:06 BST, Tony Marston <tonymars...@hotmail.com> wrote: wrote in message news:86dba466-a764-522b-6990-39fd7668a...@fleshgrinder.com... I should point out that snake_case was the universal standard decades before some people switched to CamelCase. [citation needed] My first job in computing was with a UNIVAC 1108 mainframe in the 1970s. This used a 6-bit character instead of an 8-bit byte, which meant that it could support upper case characters, but not lower case. Where a name was comprised of several words an underscore separator was used, as in "end_of_file". Lisp, for instance, uses hyphens to separate words, and has don't since the 1950s. That was only because some software could not handle long names, but could handle both upper and lower case, so an upper case character was used instead of an underscore. [citation needed] Try reading https://en.wikipedia.org/wiki/Naming_convention_(programming)#Length_of_identifiers I'm sorry, but this smells of folklore and guesswork to me. Both underscores and mixed case are workarounds for the inability to include spaces in identifiers, and have their pros and cons, most of which these days come down to opinions on aesthetics. Some studies have shown that that most people find it easier to read compound names which use the underscore separator. Look at the following: https://en.wikipedia.org/wiki/Camel_case#Readability_studies https://en.wikipedia.org/wiki/Snake_case (first paragraph) This is not guesswork on my part, it is a documented fact. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Naming in Core
wrote in message news:86dba466-a764-522b-6990-39fd7668a...@fleshgrinder.com... Hey Stas! On 5/30/2017 1:00 AM, Stanislav Malyshev wrote: Hi! People are complaining over at Reddit [1] Isn't it what Reddit is for? ;) I guess it is. ;) I know that this is probably a topic nobody cares much about, at least we did not end up in this kind of bikeshedding in the UUID discussion thread, but it is after all an important question when designing a language. I personally don't think it is a very important decision, since nothing much would change either way, but my preference would be: 1. If there's an established acronym, keep it (GMP, DOM, XML, HTTP). 2. If it's just words, use CamelCase. Second preference is all CamelCase, treating acronyms as a single word (e.g. RpcOverHttpsViaXml). Exactly how I see it. I am only asking to decide on one of both and put it into our coding standard so people who keep on complaining can be pointed there, and we're done. I should point out that snake_case was the universal standard decades before some people switched to CamelCase. That was only because some software could not handle long names, but could handle both upper and lower case, so an upper case character was used instead of an underscore. That limitation of the size of names no longer exists in any modern software, so the continued use of CamelCase is out of habit and not necessity. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Class Naming in Core
wrote in message news:b1ab1858-8ed9-802b-85a6-fe1b458a4...@fleshgrinder.com... @Tony: exactly what Rowan said. We will not change a single line of code, and nobody will be forced to do anything. **UNLESS** the code is meant to become part of the core of PHP. In that case it must follow the rules, the rules that are part of the coding standard. But if there was no documented standard to begin with then IMHO it is wrong for someone new to the project to demand that there be a standard, one of his choosing, and that all existing code be modified to conform to that standard. It is fine if you change your coding style in every file in your project where you are the only person working on. I do not consider a particular naming convention (snake_case, CamelCase, whatever) to be part of my coding standard. The only universal rule that I have followed for decades is that names be readable, concise and convey meaning. Anyone who says that they cannot read my code because it uses snake_case instead of CamelCase I will ignore. I have been using SQL for decades, and it is case INsensitive and has always used snake_case, which means that CamelCase is a waste of time. However, we are a team if changing members, and having a consistent code style The term "consistent" can be taken to ridiculous extremes, and I do not accept extremism in any form. helps newcomers to get into the code base. It, hopefully, helps future maintainers to cope better with the legacy code we are producing every day. Feel free to disagree with this, but this is reality here, and these kind of policies are established as part of any professional code base in the world. If it is so important then why did the PHP project not start off with a defined standard in this area? If it did not then it could not have been THAT important. On 5/30/2017 3:58 PM, Derick Rethans wrote: It is also really irrelevant, as function and class names are case-insensitve. cheers, Derick It matters to a lot of people, and that is why it should matter for us. Just because it matters to a bunch of nit-picking OCD sufferers does not mean that it matters to the rest of the world. I deliberately switch between snake_case and CamelCase in my code just to prove that IT REALLY DOES NOT MATTER! I can read a name in whatever style it is written, although I have always preferred snake_case, and being able to read the name and derive meaning from that name is the only thing that really matters. We are leaders of an unbelievably huge community and we must address their concerns. Addressing the concerns of nit-picking OCD sufferers it not something I would bother putting on my to-do list. It does not matter what you do, there will always be someone who will complain that it's wrong. You cannot possibly please everybody, so you can only aim to please the majority. Those in the minority you should ignore. Sometimes those concerns are complete bullshit, in that case we can and should ignore them, but in this case we actually already have a policy, it is just incomplete and I am asking to complete it. ;) Who determined that the existing policy is incomplete? -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Class Naming in Core
"Rowan Collins" wrote in message news:dc66f890-a033-4efa-8f2b-cb365c8a4...@gmail.com... On 30 May 2017 09:21:38 BST, Tony Marston <tonymars...@hotmail.com> wrote: Different projects/teams/organisations are free to use whatever naming convention they like, be it snake_case, CamelCase, studlyCaps or whatever I think the discussion here is which convention we, as the PHP Internals project/team/organisation, want to use. It's nothing to do with forcing anyone else to do anything at all. Regards, It does not matter. If there was no agreed "standard" to begin with, why should the core developers be forced to make unnecessary changes just because someone that there should now be a standard. Who gives this "someone" the right to demand a change in the name of consistency when the definition of "consistency" has not even been agreed? If it does not cause a problem then no time should be wasted in working on a solution. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Class Naming in Core
wrote in message news:9dffe898-e550-c6d6-46bd-86dcf7473...@fleshgrinder.com... Hey guys! People are complaining over at Reddit [1] about using PHP, Std, UUID, ... in other words about case. I know that this is probably a topic nobody cares much about, at least we did not end up in this kind of bikeshedding in the UUID discussion thread, but it is after all an important question when designing a language. Our coding standards are extremely unspecific about this kind of problem, the only thing that is written there is to avoid abbreviations, and acronyms are not mentioned at all: https://github.com/php/php-src/blob/master/CODING_STANDARDS#L154-L166 The question is, what would you guys want? The PHP community that follows the PSR rules is using PascalCase everywhere. The PHP core is inconsistent: The notion that this little inconsistency causes a problem only exists in the minds of nit-pickers and OCD sufferers. The definition of "inconsistency" can be taken to ridiculous extremes, as in the following examples: - class/method names don't all begin with the same letter - that's inconsistent. - class/method names don't all contain the same number of characters - that's inconsistent. - class/method names don't all contain the same number of vowels and consonants - that's inconsistent. - class/method names don't all contain the same number of uppercase and lowercase characters - that's inconsistent. The very idea that there is a "standard" naming convention that everyone should follow I find most objectionable. The only universal standard is that every name be readable and convey meaning. Different projects/teams/organisations are free to use whatever naming convention they like, be it snake_case, CamelCase, studlyCaps or whatever, and they should not be forced to change just because some nerd has made a unilateral decision which is way above his pay grade. In my project I use a mixture of styles just because I can, but as each name is readable and conveys meaning it does not cause a problem, therefore does not require any sort of solution. There are more important changes which can be made to the language other than changing it to comply with someone's personal preferences, so this ridiculous idea should be kicked into the long grass. Just my personal opinion. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces in Core
"Stanislav Malyshev" wrote in message news:a8d24d41-bd3a-0881-3fcb-9366fe974...@gmail.com... Hi! New classes within 7.2 (e.g. \HashContext) to be moved without concern for BC (e.g. \php\Hash\HashContext) Older classes (e.g. \RecursiveIteratorIterator) to be moved AND ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator) Do we really need this? I mean, it's not very likely that there's another RecursiveIteratorIterator in PHP code, and in user code it'd be namespaced anyway... It just looks like a lot of moving things around without any visible (at least visible to me) benefit. And given that no code would be able to use the long name for like 10 years, and even then why would anybody use long name if short one works In general, I don't see a point. New exts/features - sure. I agree with Stanislav. Everyone should remember that namespaces were only invented to deal with a particular problem - that of name collisions with user-land code or third-party libraries. It was NEVER intended to be applied to all core functions. Do you realise that this will break ALL existing code? For what benefit? Just to satisfy someone's personal preference is NOT enough justification. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces in Core
"Fleshgrinder" wrote in message news:04295b76-3e0d-5ea3-7b4e-d07a15db4...@fleshgrinder.com... On 2/6/2017 9:47 PM, Nikita Popov wrote: I'm strongly against use of the PHP namespace as a blanket namespace for bundled PHP extensions. The PHP namespace should be used only for functionality that is actually in some way related to PHP. For example, the php-ast extension could reasonably be namespaced as php\ast, as it provides an AST for PHP specifically. Similarly the tokenizer extension could reasonably be namespaced as php\tokenizer. Extensions which are not of this type should not live in the PHP namespace, because they don't have anything specifically to do with php, apart from the circumstance that they happen to be bundled at the current point in time. Remember that extension may move from being bundled to being in PECL and vice versa. If we decide to bundle the MongoDB extension with php, would we rename the currently used MongoDB namespace to PHP\MongoDB? If we decided to move it back to PECL, would the namespace go back to just MongoDB? Or would it stay PHP\MongoDB, despite not being part of PHP anymore? Should all new extensions be written with a PHP namespace to account for the possibility of the extension being bundled with PHP at a later point in time (even if there are no concrete plans to do so)? I would answer No to these questions. The namespace MongoDB is not, as you say, "random", it is *meaningful*. The namespace PHP is (with the exceptions in the first paragraph notwithstanding) meaningless and an artifact of the distribution mechanism, a mechanism which may change over time. Regards, Nikita I thought about this too. I hope you understood that the main reasoning for me to choose a well known namespace prefix is related to auto-loading and when to trigger it. The lack of function and constant auto-loading is a pain Not to me, it isn't! I have been using PHP since 2002 and I have never had an issue with this. Perhaps this is because I don't have weird development practices. and having well known prefixes could solve the issue since we would never require to even look at the auto-loader if the namespace starts with php. Obviously this could be solved for C extensions by allowing them to register another prefix that should not be auto-loaded: Sodium, MongoDB, ... Another solution could be to use pecl as their prefix. Although this couples it to the packaging system which might not be so nice. Any name that is tied to a company name or something else that makes things impossible for users to claim (Oracle, MongoDB, ...) is not a problem. In case of sodium that would probably be Paragon but Sodium might be fine too. I am not the judge here, the only thing I want is to ensure that this does not go unseen and that the potential of breaking something is real if we choose a random route like some others do. Not saying that we cannot do it, big ecosystems live without problems doing the same. However, it should be a very conscious choice and none that is taken lightly: meaning rules! Introducing a new rule which breaks code that has been running happily for the past 15 years sounds like a bad idea to me. VERY bad. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions
"Andrea Faulds" wrote in message news:19.45.38491.677d4...@pb1.pair.com...
Hi David,
David Rodrigues wrote:
Hello folks!
I just not understand why "function" should be abbreviated. It's about
"how
less character better"? I don't see it too much on PHP. I guess that is
more simple keep what exists current "function", that all knows about
(that
should be better than the next example):
$mapped = array_map(function($x) => $x + $y); // vs current:
$mapped = array_map(function($x) use($y) { return $x + $y });
I feel the same way. It would be nice to have shorter syntax, but it
sacrifices readability and familiarity here, and adds yet another new
keyword.
It also feels inconsistent… isn't "fn" just short for "function"? Why is it
exclusive to the => syntax?
Thanks.
If something can already be done in PHP then why the rush to complicate the
language so that the same thing can be accomplished with slightly fewer
keystrokes? The idea that you should reduce 'function' to 'fn' just to save
6 keystrokes strikes me as ludicrous. It also breaks one of the fundamental
rules of programming which is "Programs must be written for people to read,
and only incidentally for machines to execute."
Replacing proper words with TLAs or even symbols will make the language less
readable. It will also make it difficult for someone to spot a piece of
unusual code and look it up in the manual to find out what it means. Those
who want a language with hieroglyphic syntax should go back to Perl, but
please leave PHP alone!
Anybody who is in favour of such a bad move deserves to have their keyboard
confiscated and to be sent to bed without any supper.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Not autoloading functions
"Rowan Collins" wrote in message
news:ae15f883-bdba-89ea-9e6a-6e3b09745...@gmail.com...
On 29/01/2017 15:37, Wes wrote:
Curious that those who are posting here put all functions in the same
file.
So, why don't you just require_once('Namespace/functions.php') ?
By that argument, why not just require_once('Namespace/ClassName.php)? It
turns out that many people find autoloading a much more convenient and
manageable solution.
In particular, the standardisation of autoloading provided by PSR-0 and
PSR-4 has been central to the success of Composer, and the ecosystem of
reusable components that it promotes.
Autoloading functions, either one by one, or namespace by namespace, is a
logical extension of that, with all the same benefits. Unfortunately, it
has some unique complications due to the way PHP resolves namespaced vs
global function names. Please have a look through the archives of the list
if you want to know more; there's been too much discussion already to
re-hash it all here.
Regards,
While it has already been good practice to put each class in its own file,
it has never been good practice (at least with all the online tutorials and
examples that I have read since 2002) to put each function into its own
file.
Autoloading classes might be practical and easily implemented, but
autoloading functions is a can of worms, especially when you throw in
namespaces. I neither need nor want it in my code.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Not autoloading functions
"Wes" wrote in message
news:CAOv67gtxm0muzuKrQyizgkM9Pf0hn7E-iTBXpq1VV9D8aUWM=w...@mail.gmail.com...
Curious that those who are posting here put all functions in the same file.
So, why don't you just require_once('Namespace/functions.php') ?
I do, but without using namespaces.
I actually group my functions together in three files, not one.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Not autoloading functions
"Niklas Keller" wrote in message news:canuqdci945m2tddzty_tuuhdqn1xj9wjgsl_eqbyqr5f7_x...@mail.gmail.com... I'm sorry, it's unacceptable for who? Only for not defined function it would be called. If I call the same function a thousand times, the autoload will be attempted just the first time, and if it doesn't work then the script would die, exactly like classes. Any project I know that uses functions define them one per file, and each file is required one by one. Our observations are pretty different. I don't know any projects that use one function per file. I usually see a functions.php per namespace. Regards, Niklas I agree. My framework contains over 100 functions, and the idea of putting each one into a separate file is something that I would never do. The overhead of loading 100 small files is much large that loading 1 large file. Besides, when I am stepping through code with the debugger in my IDE it shows each file of a separate tab, and being forced to jump around from one tab to another would drive me crazy. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.2
"Nikita Popov" wrote in message
news:caf+90c91spfohitjgpwtevzt_wyk+htx4-tantmsshhctqq...@mail.gmail.com...
On Sat, Nov 19, 2016 at 11:18 AM, Tony Marston <tonymars...@hotmail.com>
wrote:
"Nikita Popov" wrote in message news:CAF+90c8Wox0wadAVPsP83er=
g9jbw__26ybwofasjb09ryv...@mail.gmail.com...
Hi internals!
I've submitted this RFC for PHP 7.1 previously, but didn't follow
through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.
https://wiki.php.net/rfc/deprecations_php_7_2
The RFC combines a number of deprecation and removal proposals. Each one
will get a separate 2/3 majority vote. The RFC overlaps with some
recently
discussed topics (each, binary strings) -- I'm fine with dropping these
if
someone has a more specific RFC.
I expect some of these are no-brainers, while others are more
controversial
-- please share your specific concerns.
Thanks,
Nikita
I am against the removal of the $errorcontext argument of error handler
as
this has been a valuable part of my error handler for over ten years.
Whenever trigger_error() is called with a fatal error I write all
available
details to a log file as well as sending an email. In order to obtain
additional data I use errorcontext to determine the following:
a) Was it called from a function or an object? For this I use code such
as
the following:
if (isset($errcontext['this']) AND is_object($errcontext['this'])) {
b) If it was called from an object, was it one of my database objects? If
yes, then obtain some extra information using code such as the following:
// retrieve error details from DML object
if (method_exists($errcontext['this'], 'getQuery')) {
$query = $errcontext['this']->getQuery();
} // if
if (method_exists($errcontext['this'], 'getErrorNo')) {
$errno = $errcontext['this']->getErrorNo();
} // if
if (method_exists($errcontext['this'], 'getErrorString')) {
$errstr = $errcontext['this']->getErrorString();
} // if
if (method_exists($errcontext['this'], 'getErrorString2')) {
$errstr2 = $errcontext['this']->getErrorString2();
} // if
I'm afraid you're out of luck here :/ This usage will no longer be possible
as of PHP 7.1 -- independently of the deprecation proposed in this RFC.
See: https://3v4l.org/sQBL9
Prior to PHP 7.1 $this was *sometimes* included in the symbol table (to be
more precise, whenever $this was used as a CV, rather than implicit UNUSED
operand). As of PHP 7.1 $this is never included in the symbol table. This
change is due to https://wiki.php.net/rfc/this_var.
But! This functionality is still available through debug_backtrace().
That's the correct way of fetching the $this of a parent frame, which
should always work (rather than *sometimes* on PHP < 7.1), and is
independent of the error handling mechanism.
The RFC does not specify this, it simply says "use a proper debugger". Will
I still be able to use debug_backtrace() to obtain the same information that
is available in $errorcontext?If so, this should be explicitly stated in the
RFC.
So, to clarify: Is $this the only thing from the error context you're
interested in? Or do you also use all the other variables?
I use all the other variables as well, but sometimes I need to use
$errorcontext to supply additional information
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] User defined session serializer
"Yasuo Ohgaki" wrote in message news:caga2bxyax05jbjavyxfsjyy6xia+4u14npfgywscl4aoofq...@mail.gmail.com... Hi Marco, Thank you for explaining the reason why! On Mon, Dec 5, 2016 at 11:12 AM, Marco Pivetta <ocram...@gmail.com> wrote: I voted "no" because I don't see any advantage over using a custom session save handler, besides adding more API that partially covers custom session save handlers. You mean current OO custom save handler, I suppose. Firstly, current OO custom save handler design (use of previously used internal save handler as its base class) is not good. Overriding open()/close()/etc are useless, moreover harmful. Number of bugs proved it is not good. I have been using session_set_save_handler() since 2002 to store all session data in a database, and I have never encountered any problems. Why is it "not good"? What bugs are there? I do not see the point in this RFC. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Deprecations for PHP 7.2
"Nikita Popov" wrote in message
news:CAF+90c8Wox0wadAVPsP83er=g9jbw__26ybwofasjb09ryv...@mail.gmail.com...
Hi internals!
I've submitted this RFC for PHP 7.1 previously, but didn't follow through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.
https://wiki.php.net/rfc/deprecations_php_7_2
The RFC combines a number of deprecation and removal proposals. Each one
will get a separate 2/3 majority vote. The RFC overlaps with some recently
discussed topics (each, binary strings) -- I'm fine with dropping these if
someone has a more specific RFC.
I expect some of these are no-brainers, while others are more controversial
-- please share your specific concerns.
Thanks,
Nikita
I am against the removal of the $errorcontext argument of error handler as
this has been a valuable part of my error handler for over ten years.
Whenever trigger_error() is called with a fatal error I write all available
details to a log file as well as sending an email. In order to obtain
additional data I use errorcontext to determine the following:
a) Was it called from a function or an object? For this I use code such as
the following:
if (isset($errcontext['this']) AND is_object($errcontext['this'])) {
b) If it was called from an object, was it one of my database objects? If
yes, then obtain some extra information using code such as the following:
// retrieve error details from DML object
if (method_exists($errcontext['this'], 'getQuery')) {
$query = $errcontext['this']->getQuery();
} // if
if (method_exists($errcontext['this'], 'getErrorNo')) {
$errno = $errcontext['this']->getErrorNo();
} // if
if (method_exists($errcontext['this'], 'getErrorString')) {
$errstr = $errcontext['this']->getErrorString();
} // if
if (method_exists($errcontext['this'], 'getErrorString2')) {
$errstr2 = $errcontext['this']->getErrorString2();
} // if
Saying that I should stop using $errorcontext and instead use a debugger is
very short sighted. I *NEED* to have this data available in the error log as
soon as the error happens. In several cases I cannot use a debugger as my
application is running behind a client's firewall and their security
restrictions forbid the use of a debugger from outside of that firewall.
I notice that the reason for this recommendation is "because the $errcontext
can be used to modify all references and objects in the current scope." If
this is the case then why not make $errorcontext read-only so that nothing
can be changed. I can imagine lots of people reading from $errorcontext, but
how many actually write? I certainly don't.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
Sent: Monday, September 12, 2016 12:34 PM >To: Tony Marston >Cc: Sherif Ramadan ; Stanislav Malyshev ; internals@lists.php.net >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle > >On Mon, Sep 12, 2016 at 9:32 AM, Tony Marston <tonymars...@hotmail.com> wrote: > >Sent: Sunday, September 11, 2016 11:44 AM >>To: Tony Marston >>Cc: Stanislav Malyshev ; internals@lists.php.net >>Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with >>composer/pickle >> >>On Sun, Sep 11, 2016 at 4:47 AM, Tony Marston <tonymars...@hotmail.com> wrote: >> >>Sent: Saturday, September 10, 2016 7:47 PM >>>To: Tony Marston ; internals@lists.php.net >>>Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with >>>composer/pickle >> >>Then I suggest that those who are so anxious to see of death of PEAR/PECL >>should be forced to provide a viable alternative first. Otherwise they would >>be just like those stupid politicians who try to force commuters out of their >>private cars and into public transport without realising that the existing >>public transport system is NOT a viable replacement and is incapable of >>taking on the extra load. >> >>I just want to say that PEAR as a source repository, has been dead for quite >>some time. It's filled with outdated code that has hardly seen any >>maintenance in years, and nobody really contributes to it anyway. >> >>PEAR/PECL as a package manager has historically had little utility to the >>average user apart from installing those PECL extensions which aren't >>packaged by a particular user's distribution repository. Certainly hasn't had >>any real viability in years. Trying to replace something that's inherently >>non-viable with a viable-alternative seems like a pretty moot point. > >Just because you have found no use for it does not mean that others feel the >same. How about those large numbers of websites that have to use PEAR Mailer >instead of the built-in mail() function? I personally use SVNManager to manage >my SVN repositories, and this is dependent on one of the PEAR modules, so >there is a very recent use. How many other PEAR modules have been installed >and are still is use? Do you have the download statistics for all the PEAR >modules? That would be much more accurate that all this guesswork and >supposition. > >-- >Tony Marston > >we have download statistics for pear/pecl: >http://pecl.php.net/package-stats.php >http://pear.php.net/package-stats.php >but it would be better to filter the stats to a more recent time interval like >last year or something, not sure if that is possible with the current web >interface, but you can see the recent download stats on the package page, eg: >http://pecl.php.net/package-stats.php?cid=33=876 > >http://pear.php.net/package-stats.php?pid=14=19 > Those download stats STILL show multiple downloads for multiple packages in 2016, so that puts paid to the idea that nobody uses it. Those who keep saying “none of the people I know use it” inhabit tiny groups who are *NOT* indicative of the entire PHP ecosystem. -- Tony Marston
Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
Sent: Sunday, September 11, 2016 8:32 PM >To: Tony Marston ; Stanislav Malyshev ; internals@lists.php.net >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle > > >On 09/11/2016 10:47 AM, Tony Marston wrote: >> Sent: Saturday, September 10, 2016 7:47 PM >>> To: Tony Marston ; internals@lists.php.net >>> Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with >>> composer/pickle >>> Hi! >> Then I suggest that those who are so anxious to see of death of PEAR/PECL >> should be forced to provide a viable alternative first. Otherwise they would >> be just like those stupid politicians who try to force commuters out of >> their private cars and into public transport without realising that the >> existing public transport system is NOT a viable replacement and is >> incapable of taking on the extra load. >again, nobody is trying killing PEAR/PECL. do we need to use strong >terms to make that clear ? To the average user if something is marked as deprecated it is the same as saying “do not use this feature any more”with the very next step being to kill it off completely. If you are not going to kill it then why deprecate it? -- Tony Marston
Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
Sent: Sunday, September 11, 2016 11:44 AM >To: Tony Marston >Cc: Stanislav Malyshev ; internals@lists.php.net >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle > >On Sun, Sep 11, 2016 at 4:47 AM, Tony Marston <tonymars...@hotmail.com> wrote: > >Sent: Saturday, September 10, 2016 7:47 PM >>To: Tony Marston ; internals@lists.php.net >>Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with >>composer/pickle > > >Then I suggest that those who are so anxious to see of death of PEAR/PECL >should be forced to provide a viable alternative first. Otherwise they would >be just like those stupid politicians who try to force commuters out of their >private cars and into public transport without realising that the existing >public transport system is NOT a viable replacement and is incapable of taking >on the extra load. > >I just want to say that PEAR as a source repository, has been dead for quite >some time. It's filled with outdated code that has hardly seen any maintenance >in years, and nobody really contributes to it anyway. > >PEAR/PECL as a package manager has historically had little utility to the >average user apart from installing those PECL extensions which aren't packaged >by a particular user's distribution repository. Certainly hasn't had any real >viability in years. Trying to replace something that's inherently non-viable >with a viable-alternative seems like a pretty moot point. Just because you have found no use for it does not mean that others feel the same. How about those large numbers of websites that have to use PEAR Mailer instead of the built-in mail() function? I personally use SVNManager to manage my SVN repositories, and this is dependent on one of the PEAR modules, so there is a very recent use. How many other PEAR modules have been installed and are still is use? Do you have the download statistics for all the PEAR modules? That would be much more accurate that all this guesswork and supposition. -- Tony Marston
Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
Sent: Saturday, September 10, 2016 7:47 PM >To: Tony Marston ; internals@lists.php.net >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle >Hi! > >> You seem to think that any opinion which differs from yours is wrong, >> and you try to dismiss that opinion by classing it as "abusive". I'm >> afraid this lack of tolerance for different opinions is becoming more >> and more prevalent in this forum, and I fear it will have a detrimental >> effect on the whole PHP ecosystem. > >Tony, the issue is not your opinion - which, by now, we are amply >familiar with, and to which you are fully entitled. The issue is the way >you are expressing this opinion - in a combative style bordering on >personal attack. The fact that I express my displeasure in strong terms comes from the fact that without it you would not realise how strongly I disagree. In my early days I would try to be diplomatic and gentle in my criticisms only to have them ignored. I therefore use strong words to make it absolutely clear that I strongly disagree. > I would suggest that if you are interested in your >opinion being considered and supported by others, to amend the tone as >to be more concentrated on technical merits and less on flame. > >> That is a valid opinion. Consider the fact that the Windows operating >> system was only accepted by large numbers of users as it had a "modern" >> GUI and not a command line interface. You try and release a new piece of > >In fact, Windows does have command-line interface That may be the case, but it would not have been accepted by trillions of users if it ONLY had a command line interface. >, moreover - Microsoft >recently invested significant resources into making this interface more >powerful and flexible. Moreover, many of the professional programmers >routinely use command-line tools on Windows. I’m a profession programmer, yet I don’t use ANY command line tools. The fact that SOME do is no reason to say that everybody should. > It is true that average >Windows user does not spend much time in command-line, but we need also >to remember that PHP developer is not exactly an average Windows user. > >> give them the right to force it upon the rest of the world. Most users >> are much happier with a GUI than CLI, so not providing a "modern" >> interface is showing disrespect to those users. > >That depends a lot on how you count "most users". If you talk about >Windows users, sure, you claim may have merits. If you talk, however, >about Windows users *that are PHP developers* - I'm not sure this is >true, at least without some factual backing, and it's in no way obvious. >In any case, we are a volonteer project, which means we release what >project participants build. If you or someone else will produce suitable >GUI for composer, etc. - we can discuss it. But stating that somebody >unknown should produce some software is useless - it only gets produced >when specific people volonteer their time to do it. Then I suggest that those who are so anxious to see of death of PEAR/PECL should be forced to provide a viable alternative first. Otherwise they would be just like those stupid politicians who try to force commuters out of their private cars and into public transport without realising that the existing public transport system is NOT a viable replacement and is incapable of taking on the extra load. -- Tony Marston
Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
Sent: Friday, September 09, 2016 10:08 AM
>To: Tony Marston
>Cc: PHP Internals
>Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
>
>2016. szept. 9. 10:44 ezt írta ("Tony Marston" <tonymars...@hotmail.com>):
>>
>> Sent: Thursday, September 08, 2016 9:35 AM
>> >To: Tony Marston
>> >Cc: PHP Internals
>> >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
>> >composer/pickle
>> >
>> >
>> >On Thu, Sep 8, 2016 at 9:49 AM, Tony Marston <tonymars...@hotmail.com>
>> >wrote:
>> >
>> >"Michael Morris" wrote in message
>> >news:CAEUnE0dfjJ02g2Rhkp9WvnkSXpoLzjK=tmivdbsucccgxw2...@mail.gmail.com...
>> >
>> >
>> >
>> >On Wed, Sep 7, 2016 at 3:52 AM, Tony Marston <tonymars...@hotmail.com>
>> >wrote:
>> >
>> >Typical. You create a useful tool, get your users hooked, then walk away
>> >and leave them dangling.
>> >
>> >No one owes you anything. You aren't entitled to get free updates to a free
>> >tool. If the author wants to move onto other projects, that's their
>> >prerogative. Stop with the bombastic and abusive tone towards everyone,
>> >particularly the developers, on this list.
>> >
>> >Please point out to me any words I have used which a reasonable person
>> >would class as "abusive".
>> >
>> >"Incorrect. There is a web interface which I use EXCLUSIVELY to maintain
>> >the contents of my PEAR library. Any proposed replacement which does not
>> >have a web interface I'm afraid is totally unacceptable. Command line
>> >interfaces went out of fashion when the Windows OS was first released, and
>> >anyone who still insists on using one has not joined the rest of the world
>> >in the 21st century."
>>
>> I repeat, show me any personal insults in what I wrote. All I see are “fair
>> comments”.
>>
>> >you inject your subjective opinion/anecdotal evidence as an objective fact
>> >and trying to kill the discussion instead of contributing to it.
>> >as you mentioned there is a pear package which provides a web interface for
>> >managing pear packages, but that isn't part of the pear core and hence not
>> >bundled by the php project atm, so I don't think that it is a valid
>> >argument for requiring to bundle a gui interface for composer. if people
>> >need a web interface there will be a web interface (maybe there is one
>> >already: https://github.com/composer-ui/composer-ui ) which they can
>> >install via composer.
>> >
>> >"Just because SOME people still like using a command line interface does
>> >not mean that they can force everyone else to use it. If any piece of 21st
>> >century does not come with a web/GUI interface it just shows that the
>> >author is still living in the past and is incapable of serving the needs of
>> >today's users."
>>
>> >first you are arguing in bad faith (eg. that anybody/everybody here is
>> >trying to sabotage those who would prefer a gui over a command line), then
>> >you start namecalling those who would prefer command line over gui (which
>> >is btw. plain wrong in the age of configuration management and immutable
>> >deployment where being able to have automated and reproducible deployments
>> >is a key)
>>
>> I repeat, show me any personal insults in what I wrote. All I see are “fair
>> comments”.
>>
>> --
>> Tony Marston
>>
>
>Your original request was "Please point out to me any words I have used which
>a reasonable person would class as "abusive".",
>now you are moving the goalpost to personal insults (which for the record
>still happened when calling people living in the past and such for using cli
>tools), which again shows that you are arguing in bad faith.
>Please take a moment and check out our mailing list rules at
>http://git.php.net/?p=php-src.git;a=blob;f=README.MAILINGLIST_RULES;hb=HEAD
>and please try to follow those otherwise you will be removed from this list.
As far as I am concerned the mailing list rules do not allow such things as
personal insults and abuse. Show me any words that I have used which can be
classed as either of those. You may perceive my comments to be insulting and
abusive, but that just shows that your perception is warped. The rules do not
prohibit dissenting opinions, so stop complaining that my opinion is different
from yours.
It is NOT insulting to say that people who still insist on using command line
tools are living in the past for the simple reason that the command line
interface was replaced with the GUI when the Windows OS was released in the
1990s. That is 25 years ago. Is that in the past or what? Without a GUI Windows
would not be the success it is today.
--
Tony Marston
Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
"Ferenc Kovacs" wrote in message
news:CAH-PCH5gu6Fz2wQU+n0J7MEGj9=wqR_UmxOd1BhQWriJ=2j...@mail.gmail.com...
2016. szept. 9. 10:44 ezt írta ("Tony Marston" <tonymars...@hotmail.com>):
Sent: Thursday, September 08, 2016 9:35 AM
>To: Tony Marston
>Cc: PHP Internals
>Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
composer/pickle
>
>Please point out to me any words I have used which a reasonable person
would class as "abusive".
>
>"Incorrect. There is a web interface which I use EXCLUSIVELY to maintain
the contents of my PEAR library. Any proposed replacement which does not
have a web interface I'm afraid is totally unacceptable. Command line
interfaces went out of fashion when the Windows OS was first released, and
anyone who still insists on using one has not joined the rest of the world
in the 21st century."
Where are the words in that statement that a reasonable person would
describe as "abusive"?
You seem to think that any opinion which differs from yours is wrong, and
you try to dismiss that opinion by classing it as "abusive". I'm afraid this
lack of tolerance for different opinions is becoming more and more prevalent
in this forum, and I fear it will have a detrimental effect on the whole PHP
ecosystem.
I repeat, show me any personal insults in what I wrote. All I see are
“fair comments”.
>you inject your subjective opinion/anecdotal evidence as an objective
fact
Just like everyone else who says "nobody I know uses such-and-such feature,
so we should remove it"
and trying to kill the discussion instead of contributing to it.
Oh, I see. I am only allowed to comment on an RFC if I am for it? Who
elected you as emperor?
>
>"Just because SOME people still like using a command line interface does
not mean that they can force everyone else to use it. If any piece of 21st
century does not come with a web/GUI interface it just shows that the
author is still living in the past and is incapable of serving the needs of
today's users."
>first you are arguing in bad faith (eg. that anybody/everybody here is
trying to sabotage those who would prefer a gui over a command line), then
you start namecalling
Where is this "namecalling"? Where are the instances of "idiot" or "moron"?
those who would prefer command line over gui (which
is btw. plain wrong in the age of configuration management and immutable
deployment where being able to have automated and reproducible deployments
is a key)
I repeat, show me any personal insults in what I wrote. All I see are
“fair comments”.
--
Tony Marston
Your original request was "Please point out to me any words I have used
which a reasonable person would class as "abusive".",
now you are moving the goalpost to personal insults (which for the record
Where is the personal insult in what I wrote? Where did I write "you are an
idiot" or "you are a moron"?
still happened when calling people living in the past and such for using
cli tools), which again shows that you are arguing in bad faith.
That is a valid opinion. Consider the fact that the Windows operating system
was only accepted by large numbers of users as it had a "modern" GUI and not
a command line interface. You try and release a new piece of software to
users that does not have a GUI or web interface and they will ignore it in
droves. Just because SOME people like CLI does not give them the right to
force it upon the rest of the world. Most users are much happier with a GUI
than CLI, so not providing a "modern" interface is showing disrespect to
those users.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
Sent: Friday, September 09, 2016 12:55 AM >To: Tony Marston ; internals@lists.php.net >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle >Hi! > >> There should be a rule that nothing can be deprecated unless there is a >> viable, stable, fully functioning and fully supported alternative. I do >> not like the way that some people simply say "I do not like this. I do >> not use this. Nobody should be using this. Let's deprecate it" > >You can have any rules you like, but if the original author is not >interested in the tool anymore, the only options you have are: > >1. Support it yourself >2. Pay/beg/bribe/persuade somebody to do it for you >3. Failing that, use it unsupported or switch to another tool > >That's not only how the open source works, that's how everything works - >try to get support for out-of-support commercial software (or >out-of-support hardware for that matter) and see if it's any easier. > >So yes, it is "typical" as you note - as typical as the life can be :) > >That said, if the tool is useful and being used, I completely agree that >we should make effort in keeping it supported. But we should also >account for the possibility of that effort not being successful. Then I suggest that you take steps to ensure that any drop-in replacement offers all the facilities of the current PEAR/PECL library. Anything less would probably annoy a largenumber of existing users. -- Tony Marston
Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
Sent: Thursday, September 08, 2016 1:44 PM >To: Tony Marston >Cc: PHP internals >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle > >On Sep 8, 2016 3:05 PM, "Tony Marston" <tonymars...@hotmail.com> wrote: >> >> "Pierre Joye" wrote in message >> news:caezptu4twuap1xjx+z_n+sgj1ujptyn8pj5xuvmjei2dke0...@mail.gmail.com... >> >>> >>> hi Tony, >>> >>> On Wed, Sep 7, 2016 at 2:52 PM, Tony Marston <tonymars...@hotmail.com> >>> wrote: >>>> >>>> "Pierre Joye" wrote in message >>>> news:CAEZPtU6aHYb9HsNXbXWp9q9PMoLYiJp=n1rjmspofmhbebd...@mail.gmail.com... >>>> >>> >>>>> Happy to see there are still users for this tool, Christian and I had >>>>> good fun writing it. Also you should know that this package is dead, >>>>> it has no acttve maintainer (I was the last one) and has some >>>>> limitations from to begin with, also was very handy at time especially >>>>> for shared hosting without shell access. >>>>> >>>> >>>> Typical. You create a useful tool, get your users hooked, then walk away >>>> and >>>> leave them dangling. >>> >>> >>> Ok. You seem to misunderstand the last part of my message. So let me >>> be crystal clear here. Your attitude right now is poisonous, at best. >>> Please change it. >> >> >> You may not like my attitude, but I am expressing myself without using >> abusive terms. I am simply expressing my displeasure with this RFC using >> civil, polite and non-abusive terminology. If you don't like my expressions >> of disapproval then don't try to bully me into submission as that simply >> will not work. > > > >> >>> Now about this specific comment. >>> >> >> >>> >>> So please, before you go down your big horse to insult my work and the >>> community, >> >> >> I did not insult your work as I have been using it for many years. What I >> find frustrating is that problems sometimes arise with a new PHP version, >> and nobody seems to be maintaining it. I have recently upgraded of my PCs to >> PHP7 and I had no end of problems. I had to debug and fix every error >> myself, but now I have the PEAR web interface up and running. > >This wording would have been better in the 1st place. The fact that you do not like my wording is irrelevant. I did not use any insulting or abusive terminology, so I regard it as nothing more than “fair comment”. -- Tony Marston
Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
Sent: Thursday, September 08, 2016 9:15 AM >To: Tony Marston >Cc: PHP Internals >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle > > >On Thu, Sep 8, 2016 at 9:43 AM, Tony Marston <tonymars...@hotmail.com> wrote: > >"Ferenc Kovacs" wrote in message >news:cah-pch568tpsztkwt553qvqy7jsp1tcqt5w+ot1pocdt-pb...@mail.gmail.com... > > >On Wed, Sep 7, 2016 at 9:49 AM, Tony Marston <tonymars...@hotmail.com> >wrote: > > >"Ferenc Kovacs" wrote in message news:CAH-PCH5qHdYen33Q_s7kTKM_ >8qk71v8ky6kt4fzurfawfx0...@mail.gmail.com... > > > > > > >Composer doesn't do that. > > > > >Then how come I've seen several complaints in various forums about >composer updating libraries in the background and screwing things up. > > > >That proves nothing except that your knowledge is very limited. > > > > > > > >indeed it does. > > > >I can only report what I have read in various newsgroups and forums, and >they have said that composer has screwed up their installations. If it is >capable of doing that then it is a serious issue that needs addressing. > > > >you can, but you shouldn't spread FUD but do your own research. >composer will only do something when you execute it, without providing any >actual problem, there is no way those could be refuted (FUD), and brings >nothing to the discussion. >what you have probably seen is people not using the tool properly >from my experience people usually screw 2 things up: > > 1. executing "composer update" without any arguments which will update > every package listed in your composer.json file to the latest version > allowed by the version constraints > 2. not putting the composer.lock under version control and then being > surprised that the other developer who makes a "composer install" from > composer.json can have different(eg. more recent) versions installed > > >Perhaps users could be prevented from making such basic mistakes if they had a >21st century web interface instead of the archaic command line. > >perhaps, or perhaps they would misclick, but now you are again trying to >divert the discussion from actual problems to the land of FUD. Have you considered the fact that some users think that the idea of being forced to use a command line interface *IS*a problem? Just because YOU like it is no reason to force your personal choice on everyone else. -- Tony Marston
Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
"Pierre Joye" wrote in message news:caezptu4twuap1xjx+z_n+sgj1ujptyn8pj5xuvmjei2dke0...@mail.gmail.com... hi Tony, On Wed, Sep 7, 2016 at 2:52 PM, Tony Marston <tonymars...@hotmail.com> wrote: "Pierre Joye" wrote in message news:CAEZPtU6aHYb9HsNXbXWp9q9PMoLYiJp=n1rjmspofmhbebd...@mail.gmail.com... Happy to see there are still users for this tool, Christian and I had good fun writing it. Also you should know that this package is dead, it has no acttve maintainer (I was the last one) and has some limitations from to begin with, also was very handy at time especially for shared hosting without shell access. Typical. You create a useful tool, get your users hooked, then walk away and leave them dangling. Ok. You seem to misunderstand the last part of my message. So let me be crystal clear here. Your attitude right now is poisonous, at best. Please change it. You may not like my attitude, but I am expressing myself without using abusive terms. I am simply expressing my displeasure with this RFC using civil, polite and non-abusive terminology. If you don't like my expressions of disapproval then don't try to bully me into submission as that simply will not work. Now about this specific comment. So please, before you go down your big horse to insult my work and the community, I did not insult your work as I have been using it for many years. What I find frustrating is that problems sometimes arise with a new PHP version, and nobody seems to be maintaining it. I have recently upgraded of my PCs to PHP7 and I had no end of problems. I had to debug and fix every error myself, but now I have the PEAR web interface up and running. do your homework and respect everyone here providing you the tools and language you use for your own projects. Also I strongly suggest you to consider your own view or vision as one along many, not the only viable absolute truth or usage. Thanks. Then I suggest that you learn to respect your users. There are huge numbers of developers out there who use PEAR, and they find a web interface more usable than the archaic command line. If you (and by "you" I mean everyone who works on PHP internals) wish to deprecate PEAR then you must first provide a viable alternative - with a web interface - and wait until it has become stable and been accepted by the community BEFORE you do so. Anything else would be less than professional. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
