PHP5:: namespace ennumeration.

[HarryF]

I think PHP in version 5 needs to implement a modules system like PERL. Where users can create extensions in native PHP. Allowing you to create and reuse components, etc.

Second that motion! OK you can just using includes but have a formal system for locating / loading classes would be great.

[Dr Livingston]

rather see them as tools which makes be an even better developer.

I'd have to disagree Tools do not make for a better developer; study and learning makes for a better developer - tools merely reduce your workload and the time to develop IMO; This point has been proven time and time again folks. To be a developer you have to study, you have to learn; to be a better developer this takes even more learning and study and more importantly - it takes experience.

[samsm]

Tools do not make for a better developer

But perhaps it does make for a better developer. Take two developers of equal skill and give one better tools, which creates the better end product?

My point is, better tools don't hurt and there is a correlation between the tools and the quality of development. :-)

[Dr Livingston]

Ummm.... Yer maybe though only to a certain point. For example, a specific tool might have 'x' functionality built in and the developer uses it much like a template; ie

<DB_CONNECT> 

Thus saving the developer the need to develope the script etc for the database connection and thus saving time right ? What happens when said developer moves on and the tool isn't available ? Yes, the developer has to script the connection from start; though due to using a tools functionality, the developer has no idea how to script a database connection, if you follow me ?[img]images/smilies/wink.gif[/img]

Also I might add that the quality of scripting/code based on a tool isn't universal and in most cases, questionable in the least ? Compare the quality of DW markup against Frontpage for example...

[Jeff Lange]

That is true, however even PHP is much like a tool, as there is a lot of stuff it does behind the scenes that I have no idea how it works, mainly because I'm only semi-beginner at C/C++.

I still prefer to write my own code over using someone elses class, however I use a couple of the PEAR Library classes in my webmail application, mainly because it would take me more time to write an equal-quality class, and I would lose signifigant development time. (I'm talking weeks here.)

[Dr Livingston]

There it is again. PEAR. Really, suppose I'd better get myself over to their site and have a rake around to see exactly how much it's moved on...

[Jeff Lange]

Hey, I'm not saying Pear is great, it just had 3 classes I needed to use for Deluxe Mail

[Dr Livingston]

[Taoism]

How hard can it be to implement "import"? For me it would seem you only need to impose the rule that namespaces must correspond to directories and class names to file names. You then search the include path looking for them.

Off the engine2 list this morning in response to a suggestion about namespaces and how to structure them to use directories:

It's not a question of a patch. Your email doesn't cover how the classes
live in the PHP run-time space, how they are looked up at run-time and how
they are qualified. It also doesn't cover functions/constants and variables.
Where to put/how to name the classes on the hard disk is not the issue and
never was.
Andi

Another (longer) quote in response to the same email:

VS>> That is to say, if you have a FOLDER called System/ that contains a
VS>> class Object and a folder called Machine/, one called Web/, and in
VS>> Web/ there are classes and subdirectories, say UI/, and so forth.

OK. Starting from here: If you have System/Web/UI space, does it relate in
some way to System/Web space? If not, you've got exacly what we had in NS
implementation before it was removed, replacing '/' with ':', and even
probably less, since you did not describe how classes in the same space
relate. If yes, what would the relation be?

VS>> the keyword "import" means "look in the following space for class files",
VS>> then namespaces can be as simple as having
VS>>
VS>> import System.Web.UI
VS>>
VS>> mean "load all of the files in UI directory as includes(), but on the

This is not related to namespaces per se. This is autoloading mechanism,
which can be, BTW, implemented with no relation to namespaces whatsoever.
I once wrote package system proposal which based on lines along this, but
never actually got to implementing it, and now I see PEAR has its own
packaging system, which I have no time to learn either...

VS>> The rules would be as simple as saying import references
VS>> directory/subdirectory paths, and without an import command you use a
VS>> similar syntax to reference a class which resides in a file of the
VS>> same name.

So, there must be one-class-per-file approach? Not too good.

VS>> So
VS>>
VS>> import System.Object
VS>>
VS>> means there is a subdirectory in System/ called Object/.
VS>>
VS>> But
VS>>
VS>> class Something extends System.Object
VS>>
VS>> ignores the folder called Object and looks for (and errors our on the lack
VS>> of) a file called Object.php in the folder System/.

So, you got disk lookup on each 'extends' statement? No good.

VS>> Whatever syntax you use is a minor point, be it the traditional DOT
VS>> reference or your : or :: reference.

As a side point, dot reference is no more traditional than ':' or '::'.

VS>> I have tried to follow your issues about namespaces, and I have to
VS>> say I am afraid this email may not have addressed the issues
VS>> adequately. But I hope there might be some sort of use in this idea
VS>> that would resurrect the use of namespaces. It may not be

Your idea, as I see it, lies in the field of packaging implementation.
Namespaces is not the same as packaging, though the former can be used in
the latter. The problems with namespaces were not 'how do we locate this
class on disk', but how to implement scoping and scope importing in
logical, efficient and easy-to-use way. The decision was reached that the
way we have is not ripe for putting it into the language, so it was
removed.

I think there is more too it than mapping the import keyword to a directory structure...

Cheers,
Keith.

[HarryF]

Thanks for that tip off. That it's a question of scoping I can now understand the reasoning behind this. Fair enough - it's it's not ready and effecient then probably is best to leave it out so that PHP5 can get rolling sooner rather than later.

[BDKR]

It seems to me that every single one of these "PHP vs *" debates always seems to boil down to "PHP doesn't have a decent class library". Which in my mind equates to "Nobody else has done all my work for me, so it can't possibly be as good as another language where someone has".

PHP5 will add a lot of extremely useful features, the best one to my mind being the exception handling. Namespaces are NOT a big deal to anyone who takes a bit of care with their code.

But then another criticism of PHP also seems to be "It doesn't hold my hand for me". Well tough, maybe you should learn to code a bit better.

I'm with you Phil! OO is cool and all that other enterprise buzzword'ism has it's place somewhere(?), but that said, PHP still kicks **** in spite of it.

BDKR

[M. Johansson]

I'm with you Phil! OO is cool and all that other enterprise buzzword'ism has it's place somewhere(?), but that said, PHP still kicks **** in spite of it.

BDKR

**** WARNING - RANT *******

Let me make this very clear. Object Orientation is absolutely not an enterprise buzzword. I have no idea who you have been listening to, but that is simply nothing more than utter hogwash coming from someone who has not worked with it. It's a mighty useful way of working, which can save you enourmous amounts of time. While OOP might not be the best fit in all cases, it certainly is in many, much more often than procedural coding. I'm confident almost every experienced developer here will agree that OOP is much more than an enterprise buzzword.

Anyway, regarding IDEs...

I'm seriosuly dumbfounded by all this talk about that tools don't make the developer, etc. And that we should all try to be better developers instead, for 2 reasons:

1. The language is a tool in itself. PHP is an abstraction layer for C. C is an abstraction layer for Assember. Assembler is an abstraction layer for... uh.. I have no idea. Point is, this goes all the way down to the electrical signals that goes in and out of the CPU. I have a buddy who have manipulated these pins directly - now there's a frickin' programmer! Even so, the CPU in itself is also a tool you are manipulating. At some level, you are going to be working with tools - that's just the way it is. Just because you use the very powerful web developement platform that is PHP does not make you a bad programmer, just because you can't do it C (or assember, for that matter). In the same manner, there is no shame in using an IDE or a class library when you are coding.

Sidenote: I think this is another of those male-genitalia-measuring-issues where you are supposed to do everything without help from anything. Pizza???! You pansy!!! Go shoot a deer in the forest and cook it yourself, you wimp. Using someone elses functions will not make you a wimp, not even a bad developer. (You might still be a wimp as well as a bad developer, but that is another story)

2. PHP holds your hand MORE than Java and .NET. PHP is simple to understand and work with. That is one of the main reasons it's so popular, and that's the thought Rasmus Lerdorf had when he was developing it. You don't have to worry about casting or data types when working with PHP. It works fine without separating code and content, and you can use it just fine without knowing anything at ALL about OOP. And up until just recently (and still enabled on most hosts) variables from POST and GET requests popped up as variables in your application. PHP is the very definition of handholding! When working with ASP.NET (and JSP, to a certain extent), you MUST care about data types/casting, be very familiar with OOP, and separate your code from your content. You are not allowed to "cheat".

With that said, PHP is still a great language, and I also think you can do very good OO coding with it. However, there is nothing wrong with using languages that have more extensive functionality. It will not make you a bad developer. It will not make your wang smaller.

[anode]

Assembler is an abstraction layer for... uh.. I have no idea.

Turing machines

When working with ASP.NET (and JSP, to a certain extent), you MUST care about data types/casting, be very familiar with OOP, and separate your code from your content. You are not allowed to "cheat".

Weak and/or dynamic typing is hand-holding? Is this one of those 1984 "Freedom is Slavery" things?

[Jeff Lange]

Assembler is an abstraction layer for Machine-Code, no?

In any case, I agree completely with you Mattias, even though I don't use OOP in PHP a lot because of the limitations, and I don't feel it is as important with PHP applications.

.NET and Java own PHP in terms of OOP, and no, OOP is not an enterprise buzzword, it is a very useful tool.

(PS: I hate working with assembler.)

Edit:

3 posts away from 1000

[firepages]

bugger ..

with you all the way until ...

"there is nothing wrong with using languages that have more extensive functionality. It will not make you a bad developer. It will not make your wang smaller. "

Becasue PHP is so easy , and yes it certainly does hold your hand through lots of stuff , peeps often forget , or never get to appreciate how much functionality it really has, its too easy to bookmark PHP as 'for MySQL based Dynamic webpages' etc because yes its bloody good at that , and simple to boot.

But it can do sooo much more , OOP or no OOP ... its pointless going into lists etc cos we have been there before and its a pissing match.

And whilst I have no problem using ready-made classes/applications , knowing what happens under the hood is important IMO if only for security reasons , look how many got shafted by early versions of phpBB etc.

As for the size of my wang , luckily I received a few emails today that will help with that for only $19-95 +p&p

[M. Johansson]

Becasue PHP is so easy , and yes it certainly does hold your hand through lots of stuff , peeps often forget , or never get to appreciate how much functionality it really has, its too easy to bookmark PHP as 'for MySQL based Dynamic webpages' etc because yes its bloody good at that , and simple to boot.

I agree with you entire post. PHP has an excellent functionality set, which spans far and wide. I was just responding to the claims that one should learn to be a better developer instead of using better tools.

edit - and PHP may have a more extensive functionality overall, with all those hojillions of functions. I think .NET actually forces you to write more of the stuff yourself than PHP, which luckily is rather easy, due to the excellent class library.

[Dr Livingston]

There is nothing wrong with Assembler Language actually... It just means it taxes you mentally more than high level languages such as PHP for example, though I wouldn't go back to it now... Been a few years and I need what brain cells I have

[HarryF]

PHP for Wang? (it runs on OS/2 and Novell after all)

[Dr Livingston]

HarryF - Have we not moved on from that era ?

[HarryF]

Have we not moved on from that era ?

Probably but having said that, worked at a place a couple of years back where Wang was still much in use, thanks to an incumbent Wang administrator.

Wonder what they call you if your job is to work with Wang technology?

[Sorry - just derailing the discussion]

[Taoism]

The Wangler?

Cheers,
Keith.

[Jeff Lange]

I'm a fan of the name 'Wang Technology.'

[Dr Livingston]

LoL