Namespaces

[philsturgeon]

This framework entirely ignores namespaces, yet is PHP 5.3 and up. Even if the namespacing was only on the core to avoid conflicts with other libraries this would be beneficial.

[dracony]

I wonder which libraries share a name with the core? There is support for composer packages (which are namespaced) so really that shouldn't come up. Namespaces are an unnecessary overkill in these cases. Though I do believe that there are projects with deep nesting levels and a multitide of classes where writing Class_With_A_Really_Long_Name is VERY annoying but I doubt it would ever come to this. Furthemore it's not that I dislike them personally, so if need comes I'll add these.

[philsturgeon]

Db for a start is likely to conflict. View and Debug are all class names that could easily conflict with third party code - not necessarily composer packages.

The point here is that NOT using a namespace is just lazy. Foo_Bar_Baz is an old PEAR style way of doing things that Kohana picked up on, but even they are working on PSR-0 for their codebase and switching to namespaces. I know you're flagrantly ignoring all PSR's but at least having a single top-level namespace for your code would get you some of the way there.

[dracony]

The tradeof here is: 1) namespace for core to support 3rd party libraries - users will have to use namespaces even if they don't have conflicting classes 2) no namespace for core, easier for most users, problems for those who want 3rd party libraries

Obviosly I should cater to the majority. By far not everyone will use 3rd party libraries, especially those that arent already namespaced themselves. AFAIK there are no popular 3rd party classes called DB that arent namespaced. Also the user can just as well just namespace the library, which will probably be the best solution anyway. Namespacing thee framework and using non-namespaced libraries is a broken idea too don't you think?

[philsturgeon]

Not namespacing the framework because you make assumptions about the usage is pretty broken. You just need to put "use PHPixe" at the top, which developers have been used to doing for the last few years. Namespaces are a standard party of any modern framework, and their benefits are pretty obvious, but you seem to be entirely ignoring their existence for the sake of making life easier for some developers who to be honest are by now perfectly used to basic namespace usage.

If you switched up to PSR-0 entirely, then you'd be able to use the composer autoloader with some classmaping, which would be considerably faster than your "check N + 2 locations every single time" autoloader, but thats another issue.

[dracony]

Composer autoloader doesn't support CFS, so we wouldn't be friends with it =)

Well If would be implementing namespaces I would refactor evertyhing, not just go the "just the core" way , because it would definately be a mess then. I aqctually posted a topic on PHPixie forum asking people about their thoughts on namespaces, and I'll just do whatever they decide =)

[philsturgeon]

If you're not going the PSR-0 route then you can at least cache the results, I don't see the need to do that many file_exists() checks on every single page load, as your code is not likely to change in-between user requests.

This conversation doesn't seem to be too active:

http://phpixie.com/forum/discussion/26/do-you-want-namespaces

Basically it's not just about third-party libs, its allowing your users to pick class names that they want to use. Auth for example may well be the name of a class I'd like to use, but if your auth code is in there I cant. Right now there are only a few classes, but when you eventually decide that you're missing Events and want to add that, that is another class which is not allowed - and Events is definitely a classname some folks will want to use.

So, but namespacing now you can avoid conflicts as you grow and add these general libraries (which 90% of other frameworks have) without breaking your users applications.

Phil Sturgeon

On Tuesday, 9 April 2013 at 07:56, dracony wrote:

Composer autoloader doesn't support CFS, so we wouldn't be friends with it =) Well If would be implementing namespaces I would refactor evertyhing, not just go the "just the core" way , because it would definately be a mess then. I aqctually posted a topic on PHPixie forum asking people about their thoughts on namespaces, and I'll just do whatever they decide =)

— Reply to this email directly or view it on GitHub (https://github.com/dracony/PHPixie/issues/19#issuecomment-16108256).

[dracony]

I wanted to add a tool that would generate a class map per request actually, or to be more precise I wanted to make a tool that would merge the whole project into a single PHP file, so that there would be even less disk read operations. Following the same logic: if the user is going to create a namespaced class anyway he can use a non namespaced framework. I still have a lot of mixed thoughts on both ideas, so maybe i'll go the namespace way. I'll have to give it another look.

[philsturgeon]

Woah woah woah, what? Mixing the whole project into one class is an incredibly bad idea, which is going to break a lot of shit with no real benefits. This isn't just CSS which you can jam together with no side effects…

Making a class map per request is like having a one-use cache - pointless. Once something is loaded, you no longer need it to be class mapped…

Have a short life cache, even if its 0 on dev and 30 seconds on production then its better than hitting up the file system looking for code every single time.

if the user is going to create a namespaced class anyway he can use a non namespaces framework

What?

I said if the user wants to create a class called "Auth" or "Events" then its going to break, that's not a namespaces class. To a user, all third party code (that includes PHPixie) should be namespaces, so they have complete and utter control over what they want to call their own code.

There are no "non-namespaces frameworks" other than CodeIgniter and Yii, both of which are fading fast into irrelevancy to make way for modern frameworks who DO use namespaces to avoid this sort of thing. You're actively building your new framework like its 5 years ago and I don't understand why.

Phil Sturgeon

On Tuesday, 9 April 2013 at 08:24, dracony wrote:

I wanted to add a tool that would generate a class map per request actually, or to be more precise I wanted to make a tool that would merge the whole project into a single PHP file, so that there would be even less disk read operations. Following the same logic: if the user is going to create a namespaced class anyway he can use a non namespaced framework. I still have a lot of mixed thoughts on both ideas, so maybe i'll go the namespace way. I'll have to give it another look.

— Reply to this email directly or view it on GitHub (https://github.com/dracony/PHPixie/issues/19#issuecomment-16109364).

[dracony]

Not one class)) One file. Oh I didn't mean per each request. I ment per developers request (e.g generated from command line) I worded myself in a bad way here).

[philsturgeon]

Right. Well, having environment support here will avoid forcing your developers to hop back into the command line to refresh things each time they change something. Slower is fine on development, then you want that cache running on staging and production

Phil Sturgeon

On Tuesday, 9 April 2013 at 08:38, dracony wrote:

Not one class)) One file. Oh I didn't mean per each request. I ment per developers request (e.g generated from command line) I worded myself in a bad way here).

— Reply to this email directly or view it on GitHub (https://github.com/dracony/PHPixie/issues/19#issuecomment-16109903).

[dracony]

And the Fat-Free framework effectively proves that you can merge stuff like this)

[philsturgeon]

Go for it if you like, but it sounds mental. It also abolishes any chances of using namespaces successfully, so you've got yourself a reason to not do it.

[dracony]

But it would be hell of a lot faster, which is THE point )

[philsturgeon]

If you enable APC or Zend Optimizer+ the actual class loading would be negligible compared to the crazy broken magic you're going to rain down upon your developers. The slow part is the N + 2 file_exists checks, not the include() - and THAT is what you should cache.

Phil Sturgeon

On Tuesday, 9 April 2013 at 08:46, dracony wrote:

But it would be hell of a lot faster, which is THE point )

— Reply to this email directly or view it on GitHub (https://github.com/dracony/PHPixie/issues/19#issuecomment-16110271).

[dracony]

Actually I could argue about the checks vs includes. file_exists checks take up for less io time than actually reading the files

[dracony]

I just really think there is a lot of cool stuff yet to be done with how classes are loaded and cached. I really don't want to rely on an external tool for that =\

[dracony]

Anyway I decided that the best way of taking a look is trying. I'll try converting it all into PSR-0 and composer packages, and seewhere it gets me. I don't think i'll like the result much but I'll try.

[dracony]

Would you suggest I split DB and ORM into separate packages, or keep them bundled with PHPixie like they are nwo?

[dracony]

I also closed some other theoretical issues, because it's much easier to communicate in a single thread )

[philsturgeon]

You can do as you wish, but I'd say that an ORM is totally optional so making it its own package makes sense. DB could well stay in the core.

Phil Sturgeon

On Tuesday, 9 April 2013 at 11:00, dracony wrote:

I also closed some other theoretical issues, because it's much easier to communicate in a single thread )

— Reply to this email directly or view it on GitHub (https://github.com/dracony/PHPixie/issues/19#issuecomment-16117782).

[dracony]

Well I can now obviously close the namespaces issue)