Namespaces cannot come soon enough to PHP

[mx2k]

I think the problem with PHP is that PHP developers got too drunk with "getting the job done" philosophy.

that lines up with their constant kiss everything principle. well, keeping it simple for them anyways. To keep it easy on the user, the developer has to work harder or at least smarter.

I actually wish they would slow down some, the speed and lack of planning has really kicked in and they are at a cross roads with the language. a decent road map would be nice, not to mention, if they are going to break so much bc, then maybe they should take the time to make a very clean break. like uniform style, function parameters (needle, haystack comes to mind), and IMHO,

have clean classes instead of classes like File in the SPL. Thats nothing but a hacked class wrapper around file functions with a very C procedural like naming convention, not OOP. Not to mention, clean up and comment the code base. =).

[Super Phil]

Will that fail us as well, much like the way the function library has?

Please, no need for overdramatics - the function library has not exactly "failed us", considering it gets the job done on a daily basis. As for the needle/haystack argument, I read somewhere that only 2 functions have a switched order, so the issue is not as prominent as argued.

[mx2k]

Please, no need for overdramatics - the function library has not exactly "failed us", considering it gets the job done on a daily basis. As for the needle/haystack argument, I read somewhere that only 2 functions have a switched order, so the issue is not as prominent as argued.

actually it is a prominent issue, because its one of the many symptoms of a bigger problem. 1). lack overall uniform guidelines that are followed 2). lack Customer first and usablity attitude, 3) lack of proper communication flow with the developer community.

all of which are some of the few things that are needed by a company to demostrate that they are an enterprise level company ready to deploy enterprise ready software.

don't get me wrong, i think highly of zend, but for this whole enterprise ready campaign is way beyond their current scope of abilities as long as their concept and standards of enterprise is much lower than what many developer s in this forum expects it to be as well as other developers in the world.

So if there are no improvements to object oriented structure of php, at the very least, a nice uniform version of php should be in order to build off of, esp with the IDE being built and the framework being built. small details add up to a bigger equation and sooner or later, it will catch up.

and if the developers would like more help, some decent c docmentation and some nice long articles on the structure of the code would be helpful.

but thats must my opinion

[arborint]

Will that fail us as well, much like the way the function library has?

I think there is a difference between "fail us" and "I don't like it", so let's be clear. There was a deliberate decision early on in PHP to name the functions the same as in the underlying library. That made the functions immediately useful to anyone who was familiar with that library. So the idea that PHP's libraries were named wrong is sort of silly. And to assume that you know better than the groups that build all of those libraries is even sillier. It was one of the many decisions that led to PHP's growth.

I have never really understood the PHP library naming complaints. They seemed to orignally come from Java guys who could find little else to complain about and were disturbed by PHP's popularity.

[jayboots]

don't get me wrong, i think highly of zend, but for this whole enterprise ready campaign is way beyond their current scope of abilities as long as their concept and standards of enterprise is much lower than what many developer s in this forum expects it to be as well as other developers in the world.

I am not aware of anyone in this forum who has posted in regards to Zend's performance in relation to being a CUSTOMER of Zend. Most people (or maybe everyone) is really talking about the open source effort organized by the PHP Group. We should be fair about that.

Even still, mostly I just see nit-piks against the PHP Group (though I agree that some of them are quite deserved). I've seen many posts by people who either have no experiece at the enterprise level or whose expectations aren't in-line with actuality. PHP by no means represents a model of meeting enterpise-class requirements -- but in balance, I'd say it is meeting many of the pressing needs faced by enterprise developers and that in general, the situation is improving. There is plenty of room for improvement but at the same time, there is no reason to not let the foot in the door at this point.

By-the-By: I find it ironic that one can argue for enterprise-readiness on the one-hand but on-the-other-hand is willing to justify a hard BC break (changing function signatures) for the sake of "purity". By-and-large, every enterprise I've been at has prefered pragmatism (and low-cost) versus academic purity and (expensive) re-writes. In this day of "smart" modern IDE's, do we really care that much about minor details like that? Or more aptly (because I know we fundamentally "care") -- does it matter much?

[mx2k]

I am not aware of anyone in this forum who has posted in regards to Zend's performance in relation to being a CUSTOMER of Zend. Most people (or maybe everyone) is really talking about the open source effort organized by the PHP Group. We should be fair about that.

Even still, mostly I just see nit-piks against the PHP Group (though I agree that some of them are quite deserved). I've seen many posts by people who either have no experiece at the enterprise level or whose expectations aren't in-line with actuality. PHP by no means represents a model of meeting enterpise-class requirements -- but in balance, I'd say it is meeting many of the pressing needs faced by enterprise developers and that in general, the situation is improving. There is plenty of room for improvement but at the same time, there is no reason to not let the foot in the door at this point.

By-the-By: I find it ironic that one can argue for enterprise-readiness on the one-hand but on-the-other-hand is willing to justify a hard BC break (changing function signatures) for the sake of "purity". By-and-large, every enterprise I've been at has prefered pragmatism (and low-cost) versus academic purity and (expensive) re-writes. In this day of "smart" modern IDE's, do we really care that much about minor details like that? Or more aptly (because I know we fundamentally "care") -- does it matter much?

whether opensource effort or not, zend does put out the core engine and has the most control over it. code whether open or not, is a product and any person who uses it, a customer. So what I have stated is fair from my p.o.v.

if i did project on source forge, despite that it may be os, its still a product and if i consider myself a professional, i would have an obligation to my customers, even though the product was free and the license stated otherwise.

[sweatje]

I have never really understood the PHP library naming complaints. They seemed to orignally come from Java guys who could find little else to complain about and were disturbed by PHP's popularity.

Courtesy of Jeff I thought this was interesting from a Perl perspective:
http://tnx.nl/php#chaos

It begs the questions, how can the PHP global function namespace be such a mess, and yet PHP continues on a stong path of growth while Perl stagnates?
(not based on any facts, more of an anecdotal evidence from the fact that I read all PHP related forums )

[jayboots]

whether opensource effort or not, zend does put out the core engine and has the most control over it. code whether open or not, is a product and any person who uses it, a customer.

Perhaps from your POV, but I say that is bull pucky. FOSS puts obligation on the user. If you require a different model, you need a comercial service solution that will assume the responsibility for you. Obviously, that is not going to come for free. This is why we should not equate the PHP Group to Zend regardless of how much influence the latter has on the former.

if i did project on source forge, despite that it may be os, its still a product and if i consider myself a professional, i would have an obligation to my customers, even though the product was free and the license stated otherwise.

Again, should you equally be held to the same standards as a for-profit organization that actually earns revenue based on its services and products? My point to you is that the PHP Group is doing a good job as an OSS project (even though we all agree they can improve). Expectations above and beyond that require commensuration of some sort -- at least, that is fair from my POV.

Regards.

[Selkirk]

It begs the questions, how can the PHP global function namespace be such a mess, and yet PHP continues on a stong path of growth while Perl stagnates?

PHP's global function namespace might be a mess, but perl has its own untidy corners. PHP continues to grow with Apache. Availability and popular applications like WordPress still drive PHP adoption by the masses.

[dagfinn]

Courtesy of Jeff I thought this was interesting from a Perl perspective:
http://tnx.nl/php#chaos
It begs the questions, how can the PHP global function namespace be such a mess, and yet PHP continues on a stong path of growth while Perl stagnates?

It's not a mess; it's just densely populated. It just happens to be no problem. Even if I were writing procedural code exclusively, I would be able to contain the urge to re-use the name "mysql_affected_rows".

The easy availability of all sorts of functions in PHP is supremely convenient. In Perl you need to download a module from CPAN to do simple tasks like URL encoding or basic variable substitution. And object-orientation in Perl is interesting, but not elegant.

[33degrees]

It's not a mess; it's just densely populated. It just happens to be no problem. Even if I were writing procedural code exclusively, I would be able to contain the urge to re-use the name "mysql_affected_rows".

It is a mess, because there's no consistency to naming and argument order, but it is true that this is more of an annoyance than a genuine problem. The overloaded global namespace is more problematic; although it's easy enough to avoid conflicting with the name of the current core functions, things can get messy when using third party code, and there's no guarantee that they're not going to suddenly put in a function or a class into the core that has a name you're currently using. Which is exactly what happened, and which is why we're having this discussion.

Adding namespaces would provide an easy mechanism for dealing with this kind of situation, allowing the core function and class library to grow without any fear of breaking backwards compatibility, and making it much simpler to reuse and share code.

[jayboots]

Adding namespaces would provide an easy mechanism for dealing with this kind of situation, allowing the core function and class library to grow without any fear of breaking backwards compatibility, and making it much simpler to reuse and share code.

Still, that's why in procedural paradigms you are typically instructed to prefix all of your custom global symbols. The only reason not to do so is that you intend to write everything yourself (how likely is that in the long run?). This is not a new rule or even something that is PHP specific -- its just good sense.

I suspect this concept bothers a lot of OOP folks: why call a Person class a FooCo_Person when it is a Person?? Chances are more than likely, though, that someone else also thinks their Person class is the generic holy grail of Person classes and so will also grab "Person". You see where this is going; however, to be fair, there tends to be more expressed interdependancies in OOP code such that simple names are a bit of a plus in that situation.

[mx2k]

Perhaps from your POV, but I say that is bull pucky. FOSS puts obligation on the user. If you require a different model, you need a comercial service solution that will assume the responsibility for you. Obviously, that is not going to come for free. This is why we should not equate the PHP Group to Zend regardless of how much influence the latter has on the former.

Again, should you equally be held to the same standards as a for-profit organization that actually earns revenue based on its services and products? My point to you is that the PHP Group is doing a good job as an OSS project (even though we all agree they can improve). Expectations above and beyond that require commensuration of some sort -- at least, that is fair from my POV.

Regards.

you say that is bull picky, because that is your opinion/pov. I would say that a common person would look at it as a product more so than from a FOSS p.o.v, people see free and they go to grab, usually never understanding any underlining ideals, philosophies, or even licenses behind it. (hence we are past the MTV generation and are now a cut, paste, and click generation)

There are different ways of being compensated for work other than money. It really depends on your goals. A good reputation, becoming a part of history, fame, influencing the world around you, (which are a quite a bit of worth that sometimes you can't put a price tag on).

There are also other routes, offering a free product and charge for special add-ins or development equipment, to which zend does that to some degree.

But this has become a bunny trail. My point was that the PR (public relations) picture they are trying to paint is not quite balanced with their current methodologies. And i just threw some suggestions to which they could do to help live up to that PR hype.

a uniform code base would help move php towards Enterprise Integration, which is a part of the whole current stage of..."php is enterprise ready". But again that is a suggestion and my opinion.

[jayboots]

Off Topic:

There are different ways of being compensated for work other than money. It really depends on your goals. A good reputation, becoming a part of history, fame, influencing the world around you, (which are a quite a bit of worth that sometimes you can't put a price tag on).

well....people and various organizations may practice forms of altruism but corporations are bound by law to maximize the bottom line (or rather, to maxiumize return to investors). We were talking about enterprise readiness in relationship to a FOSS project with corporate backing. I'm saying that the FOSS project itself is not the same thing as those that back it and that if we are going to discuss the corporate issues, we should do that in the context of paid support contracts from the corporate backers. Does the FOSS project have "PR" issues -- perhaps, but nothing agregious, especially considering the very open nature of the process (where ALL can be seen publically). Can we conclude that these (passing) frictives impact the service levels of paid-for-service contractors by otherwise independant entities? Maybe I'm being naive, but I don't think it wise to simply bind the free (beer and libre) part of PHP (ie: the PHP Group) to corporate issues and questions of corporate readiness.

Greetings.

[33degrees]

Still, that's why in procedural paradigms you are typically instructed to prefix all of your custom global symbols. The only reason not to do so is that you intend to write everything yourself (how likely is that in the long run?). This is not a new rule or even something that is PHP specific -- its just good sense.

It's only good sense in languages that don't support namespaces or packages of some kind, and those are a minority these days.

I suspect this concept bothers a lot of OOP folks: why call a Person class a FooCo_Person when it is a Person?? Chances are more than likely, though, that someone else also thinks their Person class is the generic holy grail of Person classes and so will also grab "Person". You see where this is going; however, to be fair, there tends to be more expressed interdependancies in OOP code such that simple names are a bit of a plus in that situation.

IMO, programming tends to be more enjoyable when it approaches natural language, and having to work with prefixed object names gets in the way.

[dagfinn]

IMO, programming tends to be more enjoyable when it approaches natural language, and having to work with prefixed object names gets in the way.

Here's the problem. TDD and refactoring lead to smaller classes. Mock testing drives the class size even further down. To uniquely identify a multitude of classes, you need longer class names just for the local project. In addition, you need to prefix to make it globally unique. The safest way to do that is a URL-like convention.

I've done that in the project I'm currently working on. The class names hover around 40 characters in length. If I want to type hint and keep the line length reasonable, I need one line per method argument.

My solution--which may or may not be the best one--is to groan in disgust and forget about type hinting altogether.

[jayboots]

I've done that in the project I'm currently working on. The class names hover around 40 characters in length. If I want to type hint and keep the line length reasonable, I need one line per method argument.

My solution--which may or may not be the best one--is to groan in disgust and forget about type hinting altogether.

Hi dagfinn.

FWIW, I try to follow the policy of only typehinting on interfaces or abstracts (if I am forgoing an interface) -- at any rate, generics. These tend to have much shorter names than concretes and help promote a reasonable level of re-use while still satisfying a minimal level of checking. If I find that I want to typehint a concrete I begin to think that my design is going astray since that would introduce harder dependancies.

Cheers.

[BerislavLopac]

There is only one rule about type hinting you should conform to, and you will be fine: don't use it.

[Dr Livingston]

If I find that I want to typehint a concrete I begin to think that my design is going astray since that would introduce harder dependancies.

You should only be type hinting to interfaces anyways. Even type hinting to an abstraction is bad news in my view...

[Dr Livingston]

don't use it.

Why? I've not once read anything that would convince me on these forums, not to use type hinting.

Why would your views be any different?

[DerelictMan]

don't use it.

Why? I've not once read anything that would convince me on these forums, not to use type hinting.

Because type hint violations are fatal and cannot be caught by a custom error handler? That's the reason I don't use them...

[Dr Livingston]

Umm...

Nope, I'm still not convinced that, that is an acceptable excuse or reason, as a lot of other languages throw fatals on those violations. The one exception with PHP is that you can't catch those violations, like you can with Java for example.

But in saying that, that is a fault with PHP - it doesn't support the functionality that Java has - but not with type hinting in it's self. Like, who is to say that in PHP6, that we won't have that same feature that Java has...

One can hope

[DerelictMan]

Nope, I'm still not convinced that, that is an acceptable excuse or reason, as a lot of other languages throw fatals on those violations. The one exception with PHP is that you can't catch those violations, like you can with Java for example.

But in saying that, that is a fault with PHP - it doesn't support the functionality that Java has - but not with type hinting in it's self. Like, who is to say that in PHP6, that we won't have that same feature that Java has...

Yeah, I should have been clearer. I absolutely love the idea of type hinting, it's just that I believe PHP's implementation is critically flawed. PHP doesn't really have compile time checks (other than syntax, etc.), so it becomes absolutely critical that any error that occurs during runtime can be handled gracefully. Since fatal errors cannot be handled gracefully, I avoid them at any cost, which means avoiding the use of type hints, unfortunately.

[BerislavLopac]

Why? I've not once read anything that would convince me on these forums, not to use type hinting.

Why would your views be any different?

Because it ads virtually no value to your code -- except some minor benefits that can equally well be implemented via in-code documentation -- while (sometimes severely) limiting your options.

And a question inspired by some of your posts above: what other languages besides PHP have type hinting? I'm not saying there are none, I'm just not aware of any. (Note: I'm talking about type hinting, not static typing. There's a huge difference.)

[jayboots]

Like, who is to say that in PHP6, that we won't have that same feature that Java has...

One can hope

The last I saw this issue mentioned on php internals, a fix for it seemed to be generally regarded favourably. The proposed patch (in the form of a new error reporting level named E_RECOVERABLE) is for PHP6 but I wouldn't be surprised to see it sooner. Several months have passed since I last heard of this so I don't know what the status of it is. To me, this is the only reasonable objection to typehinting but I think it is relatively minor -- normal testing should cover and catch these -- especially since you will likely only want to typehint sparingly anyways.

http://derickrethans.nl/erecoverable.php

Because it ads virtually no value to your code -- except some minor benefits that can equally well be implemented via in-code documentation -- while (sometimes severely) limiting your options.

No. Never does documentation adequately replace mechanics. As for "sometimes severely" limiting your options -- don't use it in those cases . Unfortunately, not using it at all means your code is subject to quite unintended uses that you might actually be better off protecting against.