Namespaces cannot come soon enough to PHP

[{RainmakeR}]

I wonder who was the bright spark that decided to add a class named "date" to the core PHP 5.1 distribution? I mean really, that must break a hell of a lot of stuff out there... hence the reason for the rather swift 5.1.1 release I suppose. Plus the notion of the SPL concerns me also, I mean, PHP does need some standards, but with each addition they cause potential for further name clashes, especially for those of us that do heavy OO with PHP. :\

[JointFillah]

From what I heard, it was Derick Rethans himself who 'secretly' pushed the date-class into a RC version...

Looks like a mess in php-dev-camp if you ask me...

First priority: Get the team work like a team again.
Second priority: Get namespaces.

Well if it was up to me at least :P

[BerislavLopac]

From what I heard, it was Derick Rethans himself who 'secretly' pushed the date-class into a RC version...

Seems like that Derick guy has been doing quite a lot of harm to the core team, I'd say. An overblown ego problems?

[jayboots]

A lot of good too if you look at the commits he has made, the docs he contributed and so on. He may be maverick sometimes but look at some of the ways others act. Pierre is basically on a witch hunt and is going around calling several devs (not just Derick) liars. Basically, this is dirty laundry being aired in a public forum. Sometimes mistakes are made during the development process and typically that means the process isn't good enough not that one or another developer is a bad egg. I hope we don't start pointing fingers.

[Forbes]

A lot of good too if you look at the commits he has made, the docs he contributed and so on. He may be maverick sometimes but look at some of the ways others act. Pierre is basically on a witch hunt and is going around calling several devs (not just Derick) liars. Basically, this is dirty laundry being aired in a public forum. Sometimes mistakes are made during the development process and typically that means the process isn't good enough not that one or another developer is a bad egg. I hope we don't start pointing fingers.

What is this? A soap opera?

I'm guessing Microsoft are lovin' this, what with them working on a LAMP alternative.

What with all these hissy fits and tears-against-the-photocopier episodes, I'm just wondering if some third-party needs to be involved to steady things...

[jayboots]

What is this? A soap opera?

I'm guessing Microsoft are lovin' this, what with them working on a LAMP alternative.

What with all these hissy fits and tears-against-the-photocopier episodes, I'm just wondering if some third-party needs to be involved to steady things...

Seems like a silly thing to say. The only reason any of the ranting is known is just because the process is completely open and in the public. So there is friction and we can see it plainly and we can attatch particpants names to it. My earlier comment suggested that we wouldn't be helping by fanning those flames, especially on a distant forum travelled by many folks who don't follow the internals list closely enough to appreciate the process.

At least no one is throwing chairs or plotting to undermine and destroy others.

[Super Phil]

http://news.php.net/group.php?group=php.internals there was a lot on this here.

[{RainmakeR}]

> I move that the class is renamed for the time being as to not
> conflict with existing codebases, and release 5.1.1
> expediently.

Yes, and that will break code again as I just explained to Sebastian
Kettler. And it will break *my* code ;-)

Derick

> Using generic names for core functionality in the global name space is a bad
> thing, no matter how convenient the name might be. That's a lesson PHP has
> learned for function names quite a while ago, let's not repeat the same
> mistake for class names.

No no, the core reserves the right to name whatever they want, it's the
userland code that is responsible for prefixing their classes.

Derick

[jayboots]

{RainmakeR} you are stirring the pot -- and for what? What will come of this (or what we can hope will come of this) is a better development/release process as well as a defined standard for introducing symbols into the namespace both from core and perhaps even userland. As you noted, this whole mess is largely the result of OOP without the lack of namespaces/modules/packages or what-have-you. Fairly much all of the procedural stuff was appropriately prefixed.

In other words, because a very important feature wasn't included, clashes like this were inevitable and we shouldn't be ready to pounce on the first dev that crossed the line (nor was Derick first -- Marcus did plenty with SPL before he was made to prefix it during the RC build of 5.1) So can we please avoid having another round of flaming PHP devs on this forum?

[{RainmakeR}]

Sorry, pot stirring was not my intention, and I agree that good can come of mistakes like this in terms of namespace development and such. I guess it's part of PHP's growing pains but there have just been so many occasions lately where this sort of thing is happening. I mean, I've committed to developing in PHP now for several years, this is where the core of my coding experience lies, so I care about the direction it takes. What annoys me and many others I'm sure is when certain members of the core PHP team act recklessly and seem to make changes willy nilly as they see fit, seemingly with a complete disregard for PHP userland. Then when asked to explain their actions the typical response is "I did this for me, I am right, you are wrong, change your code". Each time something like this happens it only pushes me more and more towards considering something else, perhaps Ruby. Some of the core devs really need to tone down their arrogance and start considering how they are impacting the development community.

[lastcraft]

Hi...

So can we please avoid having another round of flaming PHP devs on this forum?

Free speech means that you will hear things that you don't like. It's a good thing.

Regarding the comment that everyone else has to add namespaces...yer what? Almost every langauge makes an effort not to pollute the namespaces once the core libraries have been defined. These things need long periods of deprecation to allow enterprise code to catch up. Look at "assert" in Java breaking JUnit for the kind of trouble it causes. C++ created the "std" namespace as soon as it had namespaces just avoid polluting "userland" (that name says it all). As the application code sits on the top of the stack, it should be free to call things by whatever it wants. And Date is likely to be a domain term.

This is not a simple popularity contest, where if someone makes three positive contributions the dodgy one is declared good. It's still a dodgy decision. Anything that breaks backward compatibility is potentially very bad and has to have careful consideration placed behind it. Anything else is cavalier.

yours, Marcus

[OzRoy]

Yet another example of how PHP is not ready for enterprise?

And I'm talking about developer attitude here, not namespaces.

[jayboots]

Free speech means that you will hear things that you don't like. It's a good thing.

Hi. Just to be clear, I didn't say don't express your opinion -- I just hope that everyone will remember to keep decorum and so refrain from pointing fingers and flaming people. Surely you've seen some of the similar threads on this very forum that sparked such behaviour, particularly against the php devs. It is one thing to talk about process (or lack thereof) and how it impacts things, it is quite another to single out someone -- who isn't even here to defend themself. BTW, I didn't say that flaming has happened here in this thread so far; I am saying that this thread has the possiblity of leading towards that direction and I for one would see it as a pity if it did.

Best Regards.

[Dr Livingston]

An overblown ego problems?

I don't think so... You are talking about standards, and it would be typical for a generic Date class anyways. I would expect more generic classes to crop up in the future, as for Namespaces, I suppose that's something that we'll have to do without for the time being.

Ie Observer and Observable for example.

Free speech means that you will hear things that you don't like. It's a good thing.

Except when you are slandering someone, yes I would agree.

[mx2k]

I don't think so... You are talking about standards, and it would be typical for a generic Date class anyways. I would expect more generic classes to crop up in the future, as for Namespaces, I suppose that's something that we'll have to do without for the time being.

Ie Observer and Observable for example.



Except when you are slandering someone, yes I would agree.

Hey no one is getting slandered on the web......... now libel on the other hand.... or maybe even slashdotted .

[JaredWhite]

What's going on here? I totally and utterly agree with the core devs on this -- the onus is on PEAR to use a name that does not conflict with what needs to be in the PHP core distro.

Everyone talks about all the flaws of PHP...guess what? Those flaws are there because core devs did not put their foot down and implement the correct and proper way of doing things from the get-go. I applaud their current efforts to improve PHP at a more rapid and logical pace, and BC be damned, I say. I'd much rather update code to work with the latest release when it means I get a better and more powerful language.

I honestly don't know how we can have it both ways. If PHP is to get better and more sophisticated in order to compete with Ruby/Python/whatever, it's going to have to break BC for sure and without a doubt in both its core language as well as third-party libraries. That's just the way it is. If that isn't acceptable for you, then you could just switch to Ruby now, but that's sort of silly considering it's easier to stick with PHP and tweak things as the language improves.

Jared

[sweatje]

I honestly don't know how we can have it both ways. If PHP is to get better and more sophisticated in order to compete with Ruby/Python/whatever, it's going to have to break BC for sure and without a doubt in both its core language as well as third-party libraries. That's just the way it is. If that isn't acceptable for you, then you could just switch to Ruby now, but that's sort of silly considering it's easier to stick with PHP and tweak things as the language improves.

This may be stating the obvious, but the pain associated with BC is directly coupled to your target audiance. At work I control the server environment, I can code things for PHP5 and be happy. When php5.1.0 comes along I can build it on our development system, run the unit tests on the code and bang around in the apps and have a great degree of comfort in rolling out the new version as well as having access to the latest and greatest features.

Now when I work on WACT or SimpleTest I am faced with a different problem. Both of these code bases aim to as wide of an audiance as possible, meaning all sorts of php hosting configurations, etc. Both of these code bases are intended to support both PHP4 and PHP5, especially since PHP5 just has not penetrated the hosting demographics like you think it should have. This is the area where dealing with BC issues is particularly sticky: how do you code the app for the latest and the ancient at the same time without forking the code base?

[jayboots]

This is the area where dealing with BC issues is particularly sticky: how do you code the app for the latest and the ancient at the same time without forking the code base?

I suggest that when dealing with incompatible target systems you do the reasonable thing: you create a new branch and support the old branch for "as long as it makes sense". Similarly, the amount of effort you put into the new branch should correspond to the payback you expect for that branch. Yes, it is more work but that is the choice you must make for yourself: do you want to support and target two different platforms or not? There is no free lunch

[lastcraft]

Hi...

I honestly don't know how we can have it both ways.

Easy.

A new feature is announced well in advance so that well ahead of time we don't write code that will end up using it. Once a feature is changed, the old version is marked deprecated for a version or so, so that code that has used it in the past can migrate over.

That way we have continuous improvement and "userland" don't suddenly find they can't upgrade someday. Say when a new feature appears in a "release candidate" .

yours, Marcus

[timvw]

A new feature is announced well in advance so that well ahead of time we don't write code that will end up using it. Once a feature is changed, the old version is marked deprecated for a version or so, so that code that has used it in the past can migrate over.

You mean like the addition of a Date class in RC5 ? (Admitted, plans to add it existed already a couple of months)

That way we have continuous improvement and "userland" don't suddenly find they can't upgrade someday. Say when a new feature appears in a "release candidate" .

The issue i have with programming PHP is that for every project you need to figure out the installed version, the applied restrictions, (not) installed extensions. And choosing for the lowest common denominator doesn't seem very practical either..

[dagfinn]

What's going on here? I totally and utterly agree with the core devs on this -- the onus is on PEAR to use a name that does not conflict with what needs to be in the PHP core distro.

Everyone talks about all the flaws of PHP...guess what? Those flaws are there because core devs did not put their foot down and implement the correct and proper way of doing things from the get-go.

I don't get this. When PEAR Date was introduced -- how many years ago? -- was there anyone who even considered the possibility that there might be a Date class built into PHP (or any class for that matter)?

Java has a Date class, but you do have to import it. So if when "the correct and proper way of doing things from the get-go", perhaps you mean implementing namespaces first? That would have helped.

[jayboots]

Java has a Date class, but you do have to import it. So if when "the correct and proper way of doing things from the get-go", perhaps you mean implementing namespaces first? That would have helped.

I agree. It was the lack of a consistent (and consistently followed) naming policy for different groups (userland/pecl/core), a lack of features that could prevent toe-stepping and some short-sightedness when introducing more OOP features in a decidedly procedural language.

Note that the naming issues in the procedural side are fairly much non-existant. OOP designs have a tendancy to want to grab a lot of generic names so without policy and/or namespacing (or similar), clashes between groups are inevitable. The date example is fundamental for a few reasons. Some could argue that "date" wasn't even an appropriate name for the class based on what it was doing which is probably more akin to datetime; however, neither name should have been introduced as a builtin class.

I agree with lastcraft in that userland should be given the leeway to own the general/default namespace. The language already sucks up good names via reserved keywords, function and constant names; allowing it to encroach further by adding class names to the mix -- especially without namespace support -- is unreasonable and unwarrented. The core should prefix their classes. Not doing so dramatically increases the instances where they will break userland code without any good reason.

[JaredWhite]

P. S. And namespaces will be awesome and help with this particular sort of problem in the future, certainly. Yay, yay, and double-yay.

[Dr Livingston]

...I'd much rather update code to work with the latest release when it means I get a better and more powerful language.

I honestly don't know how we can have it both ways. If PHP is to get better and more sophisticated in order to compete with Ruby/Python/whatever, it's going to have to break BC for sure and without a doubt in both its core language as well as third-party libraries. That's just the way it is. ...

Ahem to that, well said. I get the feeling, that it had to be said but I wasn't prepared to say anything, in the event that it would inflame the thread, but I'm glad someone has said it.

[JaredWhite]

Oh, well thanks. I wasn't trying to inflame anything, of course -- I was just feeling sorry for the PHP devs who have 50% of the folks telling them never to break anything, and the other 50% yelling at them for holding back on a bazillion new language features and improvements!