User talk:Eloy Lafuente (stronk7)/Namespaces

Votes

(put your name/known nick under the preferred options)

• U05: TOVOTE: Allowed syntax of imports:
  • A) One import per line is required. (example)
    • (eloy) (tim) (dan) (sam) (emerrill)
  • B) Multiple imports (comma separated) per line are required. (example)
  • C) Both A) and B) are ok.
    • (damyon) (david)

• 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)
  • C) No, my friend, there is not C) here, lol.

• 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)
  • B) No (we can put it elsewhere, as far as it's autoloaded, who cares). (non-namespaced observer), (namespaced observer).

• 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.

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.

• 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 answer possibility is really an easter egg, you found it!. Also, it there are at least two more drawback of 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!

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).

---