On Mon, Jan 19, 2015 at 6:42 PM, Tony Marston <tonymars...@hotmail.com> wrote: >>>> >>>> Ah, so you admit there may be benefits? Again, I do not say that those >>>> benefits are definitely enough to justify the change in this case, but >>>> they >>>> are real, and I would like you to stop dismissing them. >>> >>> There is a big difference if a BC break which causes a minor benefit to >>> the >>> core developers also causes a major headache to the millions of >>> developers >>> who are the customers, the people who use the language to develop >>> applications. The aim should be to eliminate customer grievances as much >>> as >>> possible and not to simply ignore them. >>> >> >> You continue doing exactly what you were asked not to. > > > If I wish to complain I don't need to ask your permission. I also have the > right to respond to every post which argues against my opinion.
Somebody asked you simply to not dismiss their arguments, and you did exactly the opposite while quoting them. That's just rude and ignorant, and it will get you nowhere. If you want others to listen to your POV, you should start doing the same. This list is not a customer complaints book, it's a place for discussions. >> It's not just a "minor benefit to the core developers". It's an >> extremely unpopular feature > > > "Unpopular" means that people want to see it removed just because they don't > like it. > I don't appreciate you splitting my sentences into small pieces just to pick on them individually. I don't think I should explain you how combining words to form a meaning works. >> that often leads to debugging nightmares even for users with enough >> experience to take on senior development roles. > > > Ignorance about how PHP works is no excuse. I believe that "RTFM" is the > standard response in such situations. > Talk about ignorance ... you've ignored the new style of coding for a decade and don't want to be bothered to adapt to it for another one. TFM clearly favors __construct(), and it does it for a reason. No matter the cause, if the feature causes issues for the majority of PHP developers, you can't just give them the finger because you don't want to spend a few hours renaming Foo::foo() to Foo::__construct(). Arguing about BC breaks is one thing, but don't excuse your own ignorance with others' lack of knowledge, when they've clearly been driven into that. >> PHP 4 style coding is just unknown to the majority of users today and > > > But not for those users who started developing with PHP before version 5 > became mainstream. Your attitude seems to be "Let's ignore those boring old > farts who made the language what it is today and instead start pandering to > a bunch of ignorant newbies". > Oh, right ... cause pandering to the ignorant old farts is better than pandering to the ignorant newbies. Neither is better, of course. However, it's not me who suggested anything about pandering to a certain group, and you're in the minority, so you probably don't want to go there - being born earlier doesn't give you the advantage. >> most people assume that it is no longer supported > > > Then most people assumed wrongly. Why should one section of the PHP > community be made to suffer because of a wrong assumption made by another > part of the community? > Again, you're putting this out of context. >> (or rather, that it >> was never supported, because they don't even know it existed). > > > Just because a bunch of newbies didn't realise that a feature existed is no > reason to remove that feature. There are functions in the language that I > don't use and have no desire to use, but do you see me advocating for their > removal? > You would be, if they were causing you problems. It's 2015 and we're not talking about just a bunch of newbies. There are framework developers, evangelists, even core developers who would guess that this feature no longer exists. Nobody in the past decade has been taught to use the PHP4-style constructors. And that means that virtually all of the people who got into PHP programming during that period (and are aware of the feature) have learned it through spending hours of debugging because they wrote a Foo::foo() function. >> You're >> obviously an exception to that, and you might argue that somebody's >> lack of knowledge isn't an excuse to break all of your code, but >> please stop arguing that a handful of core PHP developers decided to >> drop a feature for their own benefit alone. That is simply not true. > > > What benefit will there be to the PHP community outside of the core > developers? Applications which don't use PHP 4 constructors will not notice > a difference, but those which do will break. Where is the benefit in that? > You're talking about complete, already running applications and completely ignoring the development process itself. It's kind of ironic that you're doing that because you don't want to spend time for development. >> Also, I haven't seen PHP4 style constructors used in years and you're >> making it sound like every PHP application on the internet uses them - >> very far from it. > > > Just because you haven't seen any does not mean that they don't exist. It > has already been pointed out that there are a large number of PEAR libraries > which were written with PHP 4 constructors and have never been updated. > PEAR is not the PHP ecosystem's backbone anymore. My point was that just because it exists, it doesn't mean that it's everywhere like you were implying. And you're stubborn, but don't stupid, so you're perfectly well aware of what I meant. Don't put words in my mouth. In fact, you're contradicting yourself here - you don't want to admit any benefit of the feature's removal in PHP7, which should mean that you do intend to upgrade, yet you're backing your claims with dependancy on PEAR code by assuming that it won't get updated ever. I don't get it ... do you really care about using up-to-date code or not? If you want to rely on PEAR forever and assume that nothing in it gets updated, then you don't care about that. So why are you arguing and not just stay on PHP 5? >> That being said, it is still a major BC issue and unfortunately we're >> not going to have PHP 5.7 where it could've been deprecated, so I >> guess being stuck with this feature (but deprecated) in PHP7 might be >> the wiser choice. >> >> Cheers, >> Andrey. > > > -- > Tony Marston Which brings us back to the ignorance ... you didn't focus on suggesting that deprecation would be better, where you would've received some support, but instead opted to argue that yours is the one and only valid opinion. All you were (kindly, compared to your attitude) asked to do was to admit that there are two sides on a coin and stop ignoring other people's opinions. When you're unwise enough not to do that, well ... have fun arguing with yourself, cause nobody's going to listen to you either. I'm out of this deadlock. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
