ElkArte Community Modern, Free, Powerful
Community building forum software

I wonder: should we use them thing?
It may make sense in some cases, but I feel like at this very moment it would be kind of a waste of time...

For example, I was looking at SP to split up the blocks and thought: "hey, maybe a \Block namespace could be nice to have", but... does it make sense?

Don't know either.

If we were to use them now, they would be in the most basic way at this point.  Of course that may be the reason to do it now (meaning 1.1) since it is easy now.  Not sure how many we would define, just a few I would think?  Maybe @Joshua Dickerson has some thoughts on this

I'd say that if you started using a root namespace at the least, it would make it easier to name classes now and later. It doesn't really take much more work. Though, if it means a lot of work, there's a lot more things to focus on - like making the entire codebase more object oriented.

Since in 1.1 I moved some "components" to their own directory (e.g. the cache or the scheduled tasks), I think these could be a good starting point for namespaces, that would also help with naming scheme and autoloading.
For example, at the moment we use things like "Eaccelerator_Cache", we could split it into namespace CacheMethod and class name Eaccelerator. That way we could change the autoloader and use the namespace as directory inside subs, and the name of the class would be the same as the file name (reducing also the current ".class.php" to ".php").

The alternative could be to go as far as Subs\CacheMethod as namespace and then in the autoloader replace Subs with SUBSDIR. That way has the advantage that we could use namespaces easily in other places as well.

Yes, but not CacheMethod. It would be a driver or adapter so the structure would normally be something like Subs\Cache\Adapters\Eaccelerator or Subs\Cache\Drivers\Eaccelerator

I think if you're going to go with namespaces, they should be clean - have your autoloader root be a virgin directory and add clean, manageable classes to them one at a time. So much of the code right now is a spiderweb of interdependencies and that causes a lot of headaches.

Yep, that would be a clean way. Though, I have to feeling that do something like that at this point, it would mean almost a rewrite of the entire package...

In 1.1 we are trying to obtain a better separation of the various features and functionalities, that may help towards that goal... at least I think...