What will the native namespace be?

[Gary Mort]

If those that will decide could think about it, I would find it very helpful for forward compatibility.

IE, if I know there will be one namespace for all platform code and it will be joomla/platform then in my own code I can start using it NOW.  IE all my class children can be

namespace crafty/crafty;

use joomla/platform as j;

class JApplicationMyname extends j/JApplication

And I can use a system plugin for now to run a simple mapping of:

class_alias('JApplication', 'joomla/platform/JApplication');

Where the plugin can be disabled if and when the platform is migrated to a namespace.

[Herman Peeren]

In general:

• as you know, it is back-slashes (\), not forward slashes in the PHP namespaces
• when you use the "use" keyword, classes can be named in your code without the namespace. Look at http://www.php.net/manual/en/language.namespaces.rules.php to see how unqualified classnames are resolved.

How I (and maybe some others) use it:

use joomla\platform\application

class Myname extends Application {
//not: JApplication
}

Joomla! allready had its own namespacing: the J is the Joomla-platform namespace, more folders down is in the name of the class (JModelBase is the Base class in joomla\platform\model). If you would keep those same names with J in front, you would end up with a double namespacing system.

Do you have to rewrite all code? Allways a nice question for exodus-threads:

• yes, if you want to use PHP-namespaced classes you'll have to put a use joomla\platform\ on top of the file. In that case you can leave the rest of the code untouched.
• but: the unnamespaced code can coexist besides the namespaced. We could keep JClasses for as long as we want to in a legacy tree; what about 10 years untouched... In the meantime we can just build new classes in namespaces. Would have been a better idea (and was also proposed) for the new MVC-classes. No need then to put "Legacy" behind those names... But well that is history; no undo-button there.

Herman

[Herman Peeren]

Subnamespaces just don't start with a backslash. So you could get something like:

use joomla\platform
class Myapp extends application\Web {
    // instead of: extends JApplicationWeb
}

Much of those Joomla-namespaces can be automatically translated to PHP-namespaces.

[Herman Peeren]

I use Doctrine in Joomla. Doctrine is namespaced. I just tell an autoloader in which directory path_to_doctrine the \Doctrine namespace can be found. The rest is under it, in the same folder-hierarchy as the namespace-hierarchy (PSR-0).

use Doctrine\ORM\EntityManager;
// (...)
$em = EntityManager::create($dbParams, $config);

The autoloader will look for a class EntityManager in file /path_to_doctrine/ORM/EntityManager.php. On top of that file it says: namespace Doctrine\ORM


use Doctrine\Common\Collections\ArrayCollection;
// and somewhere in the constructor of an article-entity:
$this->comments = new ArrayCollection();

This will let my autoloader look for a class ArrayCollection in file /path_to_doctrine/Common/Collections/ArrayCollection.php. On top of this file it says: namespace Doctrine\Common\Collections;

With those PHP-namespaces you'll get nice short classnames. In Zend-Framework, where you always had very long classnames with underscores to separate the parts, you'll now get the backslashes of the namespaces instead of the underscores. By using a "use"-clause on top you can just use the short name in your code. An advantage of that use-clause is that all dependencies are immediately clear. A disadvantage is that you cannot use variables for namespaces.

Want to use a Symfony-class to parse a Yaml-file?
use Symfony\Component\Yaml\Yaml
$config = Yaml::parse('parameters.yml');

To set this up you'll have to tell your autoloader where the \Symfony namespace can be found and it will find the Yaml-class in /path_to_symfony/Component/Yaml/Yaml.php.

In the last example you see Yaml\Yaml: the directoryname and (the same) filename. That would also be the case in Joomla. Correction on my posting above: it would be use joomla\platform\application\application to find the Application-class in application.php. It is sometimes a bit confusing... we'll get used to it.

In Drupal 8 core you can see the use of classes like Symfony\Component\HttpKernel\Controller\ControllerResolver. It is all the same principle. And yes: all Drupal developers will have to rewrite all existing code to work with Drupal 8 (but I don't think it will give an exodus in the direction of Joomla).

Grosso modo you can say that most common PHP frameworks are on the same track how PHP-namespaces are used. Would Joomla invent another system? Would that be good for easy exchange of code between the different frameworks?

Herman

[Donald Gilbert]

100% agree with you Herman.

[Herman Peeren]

Joomla has the intention to comply to PSR-1. That implies: "Namespaces and classes MUST follow PSR-0". In PSR-0 the filename and the classname are the same. A class JApplication would be in a file JApplication.php. If that is in a /application folder of the Joomla Platform, then the namespace would be joomla\platform\application\japplication if you want to be PSR-0-compliant.

I'd go for a class Application in namespace joomla\platform\application\application in file path_to_Joomla/platform/application/application.php. Because classnames are case insensitive in PHP we can still use upper case to start the classname and keep the filename in lower case. Would still work with the proposed autoloader in PSR-0.

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

[Donald Gilbert]

Herman - see these two gists for what I'm thinking with PSR, namespacing, and autoloading.

https://gist.github.com/4162595

https://gist.github.com/4162419

[Louis Landry]

I'm not sure anyone even got close to Gary's real question here.  My guess is that we will use Joomla\Platform as the namespace for all of our libraries.  I haven't talked to any maintainers or PLT members about that, but I would be pretty surprised if that wasn't what was used.  I would think the CMS or other applications wouldn't want us using the Joomla root namespace and I think the distinction is a good thing.  As for all the rest, of course we are going to adjust the names of the classes to suit PSR-0.  

As I have mentioned before our use of "J" *is* a namespace, and is what we have used since our minimum required PHP version was 4.1 to signify a Joomla class.  That will be replaced with whatever the PHP native namespace is when we make that change -- likely Joomla\Platform.  There should be little to no changes in file names since we don't use the prefixed "j" in those filenames.  The autoloader that we use now essentially enforces the same folder/file hierarchy as PSR-0, so it isn't a change.  That wasn't an accident.  All that would be left is putting a "\" between camelcased separators in class names.

That work is easy.  The harder part will be what Don is working on wrt having some modicum of backward compatibility and testing that thoroughly.  Additionally we still don't have all of our classes autoloadable.  Namespaces won't make a bunch of difference if the classes in those namespaces can't be autoloaded.  That's why we've said from the beginning of these conversations that we believe that to be a first step. Nearly there!

- Louis

[Herman Peeren]

@Donald: Yes, great, I love that solution with class_alias() to get compatibility with old classnames. I didn't know it existed, but it is a handy function in this case!

The only thing is: if your namespaces start with capital letters, so will the directorynames when using the example PSR-0 autoloader. And file/directorynames are case sensitive. Classnames not, so it would work with lower case namespace-names. Other options:

• use an autoloader that converts the filenames to lower case (what Joomla does; but that is not following the PSR-0 example and makes it more difficult to exchange between frameworks),
• or convert the directorynames to upper case.

Or maybe I'm wrong about those upper/lower case...

[Donald Gilbert]

Louis,

When registering a namespace, can you register it as a namespaced string? Meaning, would the following work:

JLoader::registerNamespace('Joomla\Platform', JPATH_BASE . '/libraries/joomla');

If not, should we use JPlatform as the namespace instead?

[Donald Gilbert]

Herman,

JLoader now has support for 3 different namespace loading schemes. One is fully lowercased directory and file names. Another is natural case, meaning if the namespace is lowercase, then so is the lookup path (same goes for if the namespace is camelcased).

The third option, which I think we should go with, is the mixed case loading of classes. This will allow the JPlatform to work as it is with it's lowercased directory structure (which is great) AND allow third party libraries to be loaded that follow the Camel\Cased directory structure (which is also great). Using this method, the loader first looks for the class in the lower cased directory structure, and if it doesn't find it, looks for it in the natural cased directory structure.

Another thing to keep in mind, the PSR-0 autoloader is just an example. Even Composer has made it's own tweaks to that example.

[Herman Peeren]

Sorry of course I meant "convert the first character of the directorynames to upper case" instead of "convert the directorynames to upper case".

[Herman Peeren]

Yes, that is no problem within Joomla, but makes it a little bit harder to use Joomla elsewhere (not that I think that is or will be a frequent usecase...).

[Louis Landry]

To be honest Donald, I don't know because I have not tried if you can give it a namespaced string.  Just a cursory look at the code seems like it would work.  That being said, I wouldn't be opposed to moving the root library path in the repository if that became necessary, or even just having the "packages" generated sort that bit out, be them tarballs or Phar packages.  I don't believe PSR-0 or PSR-1 speaks to requiring class paths to use camelcase on directory names or file names.  IIRC PSR-0 explicitly says you can use whatever case is appropriate.  Our options are fairly open on these things.

[Donald Gilbert]

I'm for keeping the current directory structure - I like the flexibility PSR gives there.

I just really want to be able to seamlessly use some of these awesome libraries available on Packagist in my client projects. It would make things so much easier, since there has been a TON of great code written that currently is out of reach. (I know I *could* use them, but my boss put the kabosh on it until Joomla supports namespacing. Helps keep development clean across the board.)

[Herman Peeren]

@Donald: I also use other stuff in Joomla. I just add an autoloader to the autoloader stack and goooo. What is the problem not to use all that great software in Joomla? What do you get more or easier when Joomla would be PSR-0 compliant? Isn't that only nice to easier use Joomla elsewhere? I probably see it wrong, but I'm curious what you think about it.

[Donald Gilbert]

Packagist.org <-- that is the benefit.

I know Joomla has a LOT of great stuff. But there's a plethora of code available for any need you may have on packagist. In a recent thread, mbabker was looking for an automated way to compress the asset files in the platform. He could write his own for Joomla, but why write something new when there are so many options available? https://packagist.org/search/?q=minify

[Herman Peeren]

Yes.... but you can use Composer/Packagist now, cann't you? Within your Joomla-installation.
Or do you want to use Composer for deployment to your clients? AFAIK, it is not intended for that: Composer/Packagist is a developer's tool.
Or do you have a different view on that?

[Herman Peeren]

BTW, the Joomla Platform is also on Packagist (5 downloads).

[Donald Gilbert]

It's just that we don't want to "deal with" namespaces until the platform we build on does. It's just the choice that was made for my company (not by me mind you).

[Herman Peeren]

Ah, thanks, now I understand. Poor you: what a wrong decision of your company to wait for that, while there is absolutely no necessity for it... All those great namespaced stuff can be easily used within non-namespaced code (as I do with Docrine). No problem.

[Donald Gilbert]

I think those 5 downloads are test downloads.

I don't like the way it is implemented there. The platform as a whole should not be on packagist, IMHO.

This is the roadmap I'd like to see (whether it happens exactly this way is beyond me)

• Starting with 13.2, have a fully namespaced platform (and compatibility layer)
• Sometime after that, separate each package (application, data, cache, date, event, etc....) into it's own repository with a composer.json
• Add each package to packagist.
• Create a "foundation" repository that uses composer to bring in all the required packages to build the foundation of the app. This is what the CMS other apps would use.
• Enjoy 21st century autoloaded and package powered development.

The benefit of going this route is that devs could adopt the parts of the joomla platform that they like, thus increasing overall user base of the platform. These same users could improve those parts, and contribute back the improvements that they made, without having to worry about breaking the whole.

Also, each package would have it's own set of unit tests to ensure great code quality using a continuous integration server like Jenkins or Travis.

[Herman Peeren]

I'd say: if PHP5.3+ is your platform, you have PHP-namespaces available...

On Wednesday, 28 November 2012 22:29:49 UTC+1, Donald Gilbert wrote:

[Herman Peeren]

Great vision. Like. +1

[Donald Gilbert]

Thanks Herman.

And sorry we hijacked your thread Gary. :)

[Herman Peeren]

BUT: if we would split the Joomla Platform into different packages, would that have any consequences for the namespaces? Probably not, but just asking... and going back to the original thread topic.

On Wednesday, 28 November 2012 22:40:59 UTC+1, Donald Gilbert wrote:

[Herman Peeren]

If we would once split the Joomla Platform into different packages, would for instance MVC-classes be in 1 package? but then the namespace would be something like Joomla\Platform\Mvc\Model, so with the package-name (Mvc) in between... Or would every folder in the root of Joomla\Platform be a different package? Or would those package-names not be a namespace? Or is splitting it up in packages not ideal after all? Only questions, no answers, sorry.

Herman

[Donald Gilbert]

They would still use the joomla namespace, it wouldn't have to be separated out into it's own.

I'm modeling a lot of my thoughts on Laravel 4. You can see how they accomplish this by search packagist for "illuminate" or by looking at the illuminate organization on github. https://github.com/illuminate

[Andrew Eddie]

On 29 November 2012 07:38, Herman Peeren <herman...@gmail.com> wrote:

Ah, thanks, now I understand. Poor you: what a wrong decision of your company to wait for that, while there is absolutely no necessity for it... All those great namespaced stuff can be easily used within non-namespaced code (as I do with Docrine). No problem.

Herman, you are entitled to your opinion but don't resort to derogatory comments.  I hope that was just an episode of "lost in translation".

Regards,

Andrew Eddie

[Donald Gilbert]

That's what I took it as.

[Donald Gilbert]

As in, lost in translation - not derogatory.

[Andrew Eddie]

On 29 November 2012 08:30, Donald Gilbert <dilber...@gmail.com> wrote:

As in, lost in translation - not derogatory.

Sure.  We just have a history of people that like to patronise who people for.  Maybe I'm a little over-sensitive to it.

Regards,

Andrew Eddie

[Andrew Eddie]

On 29 November 2012 08:34, Andrew Eddie <mamb...@gmail.com> wrote:

Sure.  We just have a history of people that like to patronise who people for.  Maybe I'm a little over-sensitive to it.

*sigh* That should be "who people >work< for".

Regards,

Andrew Eddie 

[Donald Gilbert]

It's always something, isn't it?

[Gary Mort]

On Wednesday, November 28, 2012 4:51:04 PM UTC-5, Donald Gilbert wrote:

Thanks Herman.

And sorry we hijacked your thread Gary. :)

No worries....  I might not like the psr0 convention...but I'm much happier to know what the future direction is than to not know.  And of course, I always have the CHOICE of defining things just in my own little world the way I want. :-)

[Andrew Eddie]

On 29 November 2012 09:12, Gary Mort <jooml...@gary.mort.net> wrote:

No worries....  I might not like the psr0 convention...

I think the first priority should be that our loader can consume PSR-0 code.  We should of course look to PSR-0 with this discussion, but I'm also not worried about reaching the conclusion that it's not for us and we can't completely comply.  From a project point of view we are currently more interested in being the 'lead' framework and being able to wire up other code if we want - at least that's my point of view.

If you want a use case to bounce around practicalities, take the cache package.  We want to replace it with a simplified, but backward incompatible version.  How do we best structure the namespacing to allow downstream users to use either or both at the same time.

Regards,

Andrew Eddie 

[Donald Gilbert]

Louis, 

When this discussion is had with the PLT, and the decision made, how could I participate? With PSR-0, you need Vendor \ Package \ Namespace. ie: Joomla\Cache\File or Joomla\Application\Base. I'll go with whatever the final decision is (obviously) but I would like some input.

Andrew,

I agree that our autoloader needs to be able to handle PSR-0 code first and foremost. This will get me where I want to go. :) However, 

it is my belief that Joomla should also be PSR-0 so our could could be consumed/used by others as needed. I know Joomla wants to be the leading framework, as Andrew pointed out, but I don't see that happening if our code can't be cleanly used by others. The broader we make our packages available, the more use they will get. With use comes improvement. I'll say this, the improvement of a class is directly proportionate to the amount of use it receives.

Just look at Codeigniter (CI). You could make strong comparisons between it and Joomla. Before CI ever existed, it consisted of components to the ExpressionEngine CMS. A decision was made to break out CI into it's own framework, and then ExpressionEngine was rebuilt on top of the framework it gave birth to. CI quickly became THE WEB FRAMEWORK to use for "serious" and beginner developers alike. That was a mere 6 years ago, and now it's beginning to lose relevance. One of the reasons for this is that core developers got tired of the way it handled certain things, so they quit and built their own frameworks. That's where Kohana, FuelPHP, and to some extent Laravel came from. These new frameworks, based on PSR as a whole, are quickly gaining traction. Others are seeing how easy it is to develop with these frameworks, and leaving CI for them.

I don't want Joomla to be CI, losing relevance in an advancing world with core devs leaving to build better, more flexible things. I've heard it said already that Joomla (core) has trouble maintaining long term interest from it's developers.

[Louis Landry]

Good points all around, and I don't disagree.  As for where the conversation is had, I sincerely hope and expect it to happen on GitHub in the form of a pull request.  We just aren't quite there yet.  Looking at PSR-0, I don't see how Joomla\Platform\Application\Base vs Joomla\Application\Base would really matter or be problematic.  I haven't dug into that in detail though and would certainly yield to those with more intimate knowledge and experience on the matter.

Cheers.

- Louis

[Andrew Eddie]

Right. I think we should look at PSR-0, but I'm just saying that we might also come to the conclusion that it's too disruptive to comply. Hopefully, that's not the case.

Regards,

Andrew Eddie

[Donald Gilbert]

Things that are the foundation of the platform (such as the mvc and such) should be in the Joomla\Platform namespace. (ie: Joomla\Platform\Application\Base) Everything else this is framework agnostic should go in the Joomla namespace (ie. Joomla\Data\Set)

Then, when I want to start developing an app I can use a composer.json file (https://raw.github.com/gist/4165997/b6b54067d177acb44bcdc421b153d955dccb1cf8/composer.json), run composer init and it downloads all my required packages.

When composer see `require joomla/platform` it loads in this file from the joomla/platform repo, and loads in all of it's required packages. (https://raw.github.com/gist/4165997/ce8df17ac20745381905aa18a6e08d5c7bf0b206/platform-composer.json)

Also, those who want to consume joomla code simply need to add `joomla/cache` or `joomla/environment` to their composer.json file, and it imports those files.

This is really great stuff.

[Herman Peeren]

On Wednesday, 28 November 2012 23:28:55 UTC+1, Andrew Eddie wrote:

Herman, you are entitled to your opinion but don't resort to derogatory comments.  I hope that was just an episode of "lost in translation".

Late reaction (just woke up). Sorry, nothing derogatory meant at all! I just reacted to what Donald wrote and wanted to show some compassion. Nothing cynical nor mean.

He said he wanted to use some great software available on Packagist, but that - if I understood it well - his company doesn't want to "deal with" namespaces (I read: doesn't want to use other packages that use namespaces) "until the platform we build on does" (I read: until the Joomla Platform does). He added about that choice that it  that it was made "not by me mind you". My interpretation of that is: he is not very enthusiastic about that decision of his company. I just wanted to support him with that.

Sorry if that is not well understood. I'll avoid words with emotional meaning (and "stick to the code" as some would say).

[Andrew Eddie]

On 29 November 2012 18:19, Herman Peeren <herman...@gmail.com> wrote:

On Wednesday, 28 November 2012 23:28:55 UTC+1, Andrew Eddie wrote:

Late reaction (just woke up). Sorry, nothing derogatory meant at all! I just reacted to what Donald wrote and wanted to show some compassion. Nothing cynical nor mean. 

Ok; sorry I took it the wrong way then.  

Regards,

Andrew Eddie