Votes
(voting, commenting here is already closed. Go to MDLSITE-2549 for more information)
(put your name/known nick under the preferred options)
- U05: TOVOTE: Allowed syntax of imports:
- L02: TOVOTE: Level 2 namespace:
- A) Must be always a valid Moodle API, with an special (to determine) "componentapi" subspace available for everything else.
- (eloy) (david)
- B) Can be anything except valid Moodle APIs, that are reserved for classes belonging to such APIs. (non-api example), (api example)
- (damyon) (tim) (dan) (sam) (emerrill) (ankit)
- C) No, my friend, there is not C) here, lol.
- A) Must be always a valid Moodle API, with an special (to determine) "componentapi" subspace available for everything else.
- A03) TOVOTE: Always apply for the maximum level of detail deciding the namespace for a class (The "event observers" case, currently in a non-normalized way, look for them in code)
- A) Yes (a class zzzz known to belong to component xxxx, api yyyyy, should be \xxxx\yyyy\zzzz).
- (damyon) (eloy) (tim) (dan) (david) (sam) (emerrill) (ankit)
- B) No (we can put it elsewhere, as far as it's autoloaded, who cares). (non-namespaced observer), (namespaced observer).
- A) Yes (a class zzzz known to belong to component xxxx, api yyyyy, should be \xxxx\yyyy\zzzz).
- S03: TOVOTE: Global scope class backslashing (from namespaced code):
- A) is always required. (moodle global scope example), (php global scope example).
- (damyon) (eloy) (tim) (dan) (sam) (emerrill)
- B) is forbidden (because access is provided by importing the global scope class). (moodle global scope example)
- (david)
- C) Both A) and B) are ok.
- (ankit)
- A) is always required. (moodle global scope example), (php global scope example).
Comments
Damo: U05: Can't see why we would need to be so prescriptive.
- Eloy: well, that what the voting is about
Damo: L02: Even in a core plugin I can see that there could be complex code that would benefit from 2nd level namespaces - e.g. quiz. To ban them and reserve them only for core apis is again - too prescriptive.
- Eloy: note that option A provides a way for developers to own an entire sub-namespace ("componentapi") so then can use it and sublevels freely.
Damo: A03 For stuff where this is known it makes sense to standardise.
Damo: S02: A) Because that's how I've done it and I rule.
- Eloy, LOL
David Mudrak (talk) 01:03, 13 February 2014 (WST):
- UO3C - long names would span over multiple lines anyway
- L02A - because it really sucks to explain to our poor add-on developers that they have to refactorize their code just because we started to like some keyword, too. It's enough we already suffer from this heritage in activity modules prefixes.
- Eric: To me, I would rather have the freedom as a contrib dev. Things frequently break between major versions, so that is always a risk. You could provide a know, safe, namespace, but don't *require* it's use. I would rather have the shorter namespace and risk a collision that I need to fix down the road. Here is an (example) of what I have being doing at the moment.
- Eloy: Offtopic, and said with love, it's the 2nd time I hear from you about that "freedom" opinion. And, while I understand your point... I also thinks it's a bit nonsense: 1) I want freedom in my addons 2) I want to follow coding-standards 3) As far as coding-standards do not provide me freedom 4) I push to change coding-standards to, officially, get freedom. Again, just arguing by the pleasure of arguing (in my side), but up to some degree I see your point that way. Surely wrongly, lol, but hey, it's my opinion.
- Dan: But the problem is I can't see everything always naturally fitting into a core api and so that is where I/we want freedom. Rather than forcing it under some core api prefix which is not natural. (GRR. WHY do we insist on using the wiki as a discussion tool. Grr. It sucks.)
- Eric: Eloy - To me, that logic would only make sense if I am to treat Moodle HQ as a black box that stuff comes out of. There was a discussion going on about this topic, so I'll put in my opinions, and they should be weighted by people for what they are worth (not much). Also, I am not trying to change existing policy - once a the decision is made, I will abide by it. Freedom vs Prescription isn't black and white, I tend to lean towards freedom. That doesn't mean I feel there shouldn't be rules, and plenty of them. I aspire to one day write more than just some patches and contrib modules, and write honest to goodness core code, so I follow these discussions as close as I can, and sometimes participate - I try and walk the fine line between being involved, and being a nuisance (sometimes I fail at that). And I know you argue with love - no Moodle policy discussion would be complete without strong opinions from Eloy :)
- David Mudrak (talk) 15:40, 13 February 2014 (WST): This is a bit of paradox. I actually vote for L02A to make sure that add-on developers are 100% free to organise their namespace as they want (by putting the third and deeper level to their total control). With the B option, we say "you can do whatever you want, unless we decide one day that we want to do it too - and since that day, you'll be blamed for being in collision with the core".
- Eloy. Yeah, in my mind L02A was perfect because it gives to the developer 1) Complete freedom to the non-namespaced area under "classes", 2) A complete, fixed for everybody level 2 namespace where freedom is absolute, 3) The guarantee that both 1) and 2) won't change ever. 4) that very same "componentapi" space can be used in the future to move stuff from core non-oop plugins (mod/xxx/locallib...) in a perfect way/fit and 5) Simpler and clearer rules for everybody, so directories under classes always will be core APIs and nothing else. In the other side, with L02B ... yes, you can create your own level 2 namespaces and ... where is the benefit? L03 will arrive and your cool namespaces will be doomed, LOL.
- Eloy: Offtopic, and said with love, it's the 2nd time I hear from you about that "freedom" opinion. And, while I understand your point... I also thinks it's a bit nonsense: 1) I want freedom in my addons 2) I want to follow coding-standards 3) As far as coding-standards do not provide me freedom 4) I push to change coding-standards to, officially, get freedom. Again, just arguing by the pleasure of arguing (in my side), but up to some degree I see your point that way. Surely wrongly, lol, but hey, it's my opinion.
- A03A - it just makes sense
- S03B - I \just \can't help \myself but I soooo \dislike these backslashes when looking \at the code. PLEASE. (edit: after spending more time with this, I can understand why to go the A way - such as PHP bug 60022 or following what other frameworks like Symphony, Doctrine or Drupal do). But it still makes me a sad panda :-/)
- Eloy: hehe, I was aware of that problem from Drupal (only affects php global scope, not moodle global scope, afaik), and that S03B answer is really an easter egg, you found it!. Also, there are at least two more drawbacks with this option. First, its maintenance (to keep the list of imported classes on sync with code, on deletions and so on). And second, it really does not provide any interesting information to know that, along a class, you are going to use, say, stdClass or FileIterator or whatever. And the list can be huge!
- David Mudrak (talk) 15:48, 13 February 2014 (WST): Yeah... Reading the Drupal's story was a good lesson for me as their original reasoning was exactly the same as mine. And then they ran into these troubles which led them to changing the coding style. I agree, maintenance of the "use" section would be a hell. And who knows, maybe PHP will one day decide that they search the global scope. At the end, it might finally motivate us to put as much of the code into some namespace so we do not really need it. Meanwhile, I'll just use $a = (object)array(); ;-)
p.s. I know it's out of scope of this issue, but I see it a shame that (generally) namespaces in PHP do not really help to prevent collisions in 3rd libraries. Particularly (again from our add-on developers' POV) I know a case when two add-ons ship with the same 3rd party lib. Namespaces really do not help much if one would like to keep 3rd party libs untouched.
p.p.s. To be completely honest (and I know this will be completely out of scope), I still do not see namespaces much useful in Moodle codebase at all. If we were pretending that Moodle code can be composed by reusable components found here and there, then our namespace would have to start with vendor name, i.e. \Moodle\... This is not our case. And we have established and working conventions (frankenstyle prefix) that solve the collisions well. I can't stop thinking that this will just add another layer of code style inconsistency (as I am not naive enough to believe that one day we rewrite everything to use namespaces).
- Eloy: I only can agree 100%. Autoloading was the excuse, since then the tree has been growing without control... time will tell if the fruits are tasty or nasty. I'm sceptic too. But fun is guaranteed!
- David Mudrak (talk) 15:40, 13 February 2014 (WST): As far as my puny brain can absorb, autoloading was doable without namespacing. But I was not really involved much so I may miss some bit there. It's just a feeling/intuition that we brought something into our world just because we could. And I just can't see much benefits (and I can see much cons, such as loosing the ability to quickly grep for class names etc). Shortly, we are not Symphony. And having namespaces does not put us closer to them. IMHO.
- Eloy: Yeah, autoloading works for non-namespaced classes. I tried to explain it @ Eloy Lafuente (stronk7)/Namespaces, problem is somebody thought namespaces autoloading was going to be a nice addenda, and that leaded to the current "gates are open" for them.
- David Mudrak (talk) 15:40, 13 February 2014 (WST): As far as my puny brain can absorb, autoloading was doable without namespacing. But I was not really involved much so I may miss some bit there. It's just a feeling/intuition that we brought something into our world just because we could. And I just can't see much benefits (and I can see much cons, such as loosing the ability to quickly grep for class names etc). Shortly, we are not Symphony. And having namespaces does not put us closer to them. IMHO.
