Namespace F3 - become PSR-4 Compatible. #110
Comments
|
I agree 👍 I also faced name collisions a few times. Nothing that couldn't be worked around, but it would certainly be cleaner to have all the framework stuff stored in one dedicated place. That could come in next major release (v4). |
|
I also agree but I think that it's too late for |
…3-factory#110. Required following refactoring most of which was automatable: * Add `namespace F3` to all top level files programatically, and amend the namespace of files that already had a namespace to include prefix `F3`. * Replace all relative refs to non F3 classes in the to level with absolute refs. * Amend all absolute refs to F3 class in non top level classes. * Minor touch up to autoloader - use require_once() not require(). * Fix some implicit refs to non prefixed namespaces in Preview::token(). * The sample app and test at /bcosca/fatfree will have to be updated. Already done sucessfully. Will push shortly.
|
Just completed, looks good. Used vendor namespace "F3" as guess that would be the preference given its succinct and all. See #112 and bcosca/fatfree#901 |
|
this is highly needed. i just faced same issues as stated above where F3 has already taken names and it started having conflicts with some of my classes. Though simple renaming of my classes fixed issues but that shouldn't be the case, Fatfree is still a dependency so it should act like one. |
|
Given that F3 is the framework you rely on, it should be the app that should adapt - not the other way around. Would jQuery give up the $ because you want it? F3 gives you a lot of freedom - but not bordering on anarchy. |
False analogy. Yes, Javascripts are expected to respect namespaces. Take a look at npm ... |
I strongly disagree with that. Every class in PHP must use namespaces nowadays. Only native classes provided by the SPL do not need so, and that's how you know they are core classes. A framework is still a library, even if it's the core of an application. |
|
Hi @bcosca, you've done awesome well with F3 but i disagree on this. F3 is just a library and my app is designed in a way that i can or should be able to change/swap any of the used dependencies at anytime without much issue should the need be, even F3. It is not designed to be coupled to just one framework. Now this aside, here is an example: there was a need for me to create my own View class that suites my app specific needs but F3 is already using View so i had to namespace View class which to me isn't proper. My App classes should be first class citizen in there own country/home and should have preferential treatment and not a second class citizen :) right-now F3 has dominated and made them second class citizen :) building on @nanawel example, following your logic, say i have a class named Services and for whatever reasons your decide to have a new class in F3 named Services or i am replacing an existing library/framework with F3, does that mean i will have to rename my Services class or any other existing classes in-order to use F3 or the new F3 release? |
|
I have to say that both sides of this argument are valid but not equally IMHO. Sure, applications can alter their class names or better yet use namespaces to fit in to a framework or a library and say avoid collision issues BUT so could F3... and if F3 adopted name spaces then wouldn't that be cleaner in that it wouldn't matter what applications decided? F3 adopting name spaces kind of seems to make the most sense. Applications (that use any framework including F3) should also adopt names spaces IMHO as well but it really would be up to the developer. Perhaps its my heavy Java background that comes into play here but explicitly using name spaces just makes the most sense all around and for me that includes F3. Just my 2cents. BTW love F3 - as a Java developer I have to say F3 is the only reason I use PHP at all :-) |
|
All valid points for sure, and its integration was already blessed for v4, but it would just be self-destructive for any other mid-release. |
|
We had a fork that built namespacing into F3 but nobody continued to work
on that just because the existing user base has to adopt it in the future.
That was long before like everyone started actively using composer.
I mean, the project is open source. Feel free to fork the current code base
and update it to use name spacing. Release it as 4.x and let 3.6 die in
piece.
…On Thu, Apr 13, 2017, 17:49 nikolaosinlight ***@***.***> wrote:
I have to say that both sides of this argument are valid but not equally
IMHO.
Sure, applications can alter their class names or better yet use
namespaces to fit in to a framework or a library and say avoid collision
issues BUT so could F3... and if F3 adopted name spaces then wouldn't that
be cleaner in that it wouldn't matter what applications decided?
F3 adopting name spaces kind of seems to make the most sense. Applications
(that use any framework including F3) should also adopt names spaces IMHO
as well but it really would be up to the developer.
Perhaps its my heavy Java background that comes into play here but
explicitly using name spaces just makes the most sense all around and for
me that includes F3. Just my 2cents.
BTW love F3 - as a Java developer I have to say F3 is the only reason I
use PHP at all :-)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#110 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAC_snyP0QTFMwlsBtMcXnW4rJ26Tevlks5rvkQdgaJpZM4G-pvX>
.
|
|
Hi @ikkez, wasn't aware it was blessed for v4. Reading the thread @xfra35 mentioned "That could come in next major release (v4)". Good to know - Thank You. In any event, it definitely would be a change that forces code modifications on users of F3 but isn't it a little much to consider it "self-destructive" if done in the 3.X stream. I personally would rather see this in F3 sooner vs. later as yes this affects code but it is a pretty simple straight forward change unlike the changes that may come with v4 which may hold me back from upgrading until I am a) able to tackle those changes / new mechanisms and b) consider that v4 is stable enough to deploy on which may or may not be the case with a .0 release. Point is - some times within a mid release there is some minor pain involved and in this case I disagree that it is anything so great that it could be labelled "self-destructive" but YMMV... :-) BTW love F3 and love Cortex - Much appreciated! |
|
Well, maybe I like to dramatize things a little ^^ I'm also wondering if we are ever able to work on the v4 again, as everyone seems pretty busy and its early beginning was already 2 years ago. So yes maybe it could also be considered for 3.x.0 |
|
For me i am well aware Namespace has been blessed already for V4 but also as @ikkez just stated and @bcosca also hinted a while back in the google forum, V4 name tag is more of a dead idea and the initial v4 codes are slowly creeping in into V3.x. it makes sense to consider namespace to also creep in as well as soon as could be possible. The changes this will bring to existing app is minimal in MHO. |
|
Just to be irritating, I'll +1 this. When is v4 slated to come out? Sometime in the next 6 months? Year? Ever? Releases seem to have slowed a bunch on F3, however that could speak to the simplicity of the framework. If there are only so many moving parts, eventually all the common kinks get worked out. |
|
Also +1'ing this. I'd love to use F3 for some new projects and mix in some of my favorite template composer packages but I really don't want to stress about collision. @ikkez Would it be possible to turn v4 into JUST what's existing in v3 + the namespace change? And then we shuffle anything new into v4.1? I'd be happy to help. |
|
i so so so support this idea. namespace is needed now. |
|
we finally made progress on this 😅 |
F3 should have a top-level namespace AKA vendor namespace, in order to be PSR-4 compatible. Something like
F3\, orFatfree\or what owner wants. Yes you can use PSR-4 autoloaders and composer autoloaders with F3, but the top level namespace should belong to the local application not a dependency. F3 is stepping on shoes (mine at least). For example, I have a local only classView, but that name is taken, along with a bunch more by F3 so I have to change it.This has come up before as bcosca/fatfree#741, but I wanted to re-raise it here. I will re-factor code base if there is consensus, but not bothering if it won't be accepted.
Note on BWC; It will break, but I'm not saying merge into master just yet. Upgrade is a simple matter of prepending
namespace F3to existing PHP files unless you referred to classes explicitly in the global namespace. Then you'll have a bit more refactoring but nothing hard.The text was updated successfully, but these errors were encountered: