I've been messing with PHP5 for the last few weeks and am curious how people deal with the lack of packages. Here I don't just mean a collection of code, but packages in the sense that for example Java uses them. I'm very use to organizing my code with packages (and limiting access etc), that I find this pretty annoying.

What exactly do you find annoying about it? PHP doesn't have the concept of namespaces as you are used to in Java. It also doesn't have the concept of packages (like Java or Python).

So -- my question again -- what do you want to do? Organize your classes? Setup a file structure? What exactly?

I've never used Java to any great extent, but I know that code organization is something that I've been working on lately. I' just create a standard set of folders and try to setup my code into modules. Each module has the standard folder set of lib, controller, views, helpers, external. I also have a project wide set of those folders and the sitewide includes a folder called modules.

This seems to be working out ok for me so far. The nice thing about php is at least you have the freedom to just do whatever makes sense to you since there is no preset method.

You can obviously set up a file structure with PHP. As I said I want to be able to make packages, and of course php doesn't have the ability to do this. So I was curious how people deal with this.

So for example, if you have a collection of files that contain classes, there is no way to have one facad to the whole collection. Someone could also come along and call any class in the collection. This I find really undesirable.

Originally posted by Froggy
So for example, if you have a collection of files that contain classes, there is no way to have one facad to the whole collection.

You mean facade?

http://www.litfuel.net/plush/?postid=35

Yes I mean facade, and my point is that someone can still call any of the classes behind the facade in PHP, I don't see what stops this.

In Java and other languages you can have package private classes that cannot be accessed out of the package. You can also have methods that are can be accessed by members of the package.

Well to anser your original question. I personally have never missed packages. I've always just used my classes as intended and if someone wants to use them inappropriately and call members of a class that should be private more danger to them.

PHP != Java and in the end people can go in and edit your code if they really want access to something.

This isn't about members of a class, with PHP5 you can define methods as private/protected/public. In general the new OO stuff in PHP5 is nice, I wouldn't even bother with OO design in PHP4. But you cannot define classes as private/public and that is the issue.

Why don't you request this as a feature by logging into the bugs.php.net? If it really matters to you -- tell it to the people that have the power to change things for you.

You might also want to join the php.internals list if you want to talk to some of the people behind php.

Or, if you really feel adventurous -- and since PHP is open source, download the source and try to implement it yourself.

put all your classes in a single file and there's your package. lol.

Hm, honestly it never occured to me to even think about the usage of packages in PHP. How would that work with PHP anyways? Even now that I realize it, I don't find myself having an urge to use packages in PHP.

I would imagine if this was something they could've added easily they would have. I'm certainly not going to spend months trying to add this feature to PHP. I started the post because I was interested to see if any others found ways of dealing with this in PHP. By that I mean alternative ways to organize code.

Since PHP doesn't offer a package-like function; the field is pretty much open to how you organize your code.

Depending on the type of project and code involved, I follow any number of strategies. For example, if the project involves a central code-base, I usually store these files outside of the document tree, and then create links to them in the actual project's directories.

This way, if a new version of the core is developed, I only have to change a symlink -- and can easily roll-back to older revisions. Plus, revisions of the code-base are reflected instantly in all applications that refer to it, so there is lack of duplication.

As far as naming goes, I have settled into the following scheme:

class.classname.php (for classes)
inc.description.php (for non-class function libraries)

One tip, avoid giving your PHP files other extensions unless you configure your webserver to recognize these as php files. If you have a file called db.php.inc and its browsable -- then anyone can simply request the file and your webserver will display it. Depending on the configuration, it may ask the user to download it, or display the code in the browser!

Although lacking a 'package-and-deploy' type service as some other languages, many PHP developers have created their own strategies of creating modules and very simple versions of 'auto-deploy'.

A good example of how this works is Drupal. Each module that is developed follows a strict naming convention, and provides hooks to the central Drupal system. This allows the end user to simply upload the file to the modules directory, and Drupal will recognize the module, read its 'hook functions', and have it installed instantly.

So, the options vary, and its generally 'it works for me' -- as there is no 'standard' method defined by PHP.

Yes I know there is no standard method, thanks for your input.