text: Feedback
  Getting Started
  Discussions
  Site operation discussions
  Recent Posts
  (new topic)
  Departments
  Courses
  Research Papers
  Design Docs
  Quotations
  Genealogical Diagrams
  Archives
  This is a question that I encounter frequently when thinking about OOP and modules.
  Say, I define a method m on some class inside a module M.
  m
  M
  Should the method lookup table of the class contain an entry named "m" or "M::m"?
  "M::m" seems cleaner, and more modular... whereas "m" seems more OO.
  Usually, methods are not first class and can only be used in combination with an object reference, which then indirectly serves as a namespace.
  If you want methods to be first class, where you want to refer to a method "m" without mentioning an object or class, then I would use "M::m".
  The best reference implementation for namespaces, IMHO, is .NET's MSIL (Microsoft Intermediate Language) for the CLR (Common Language Runtime). The ILAsm, when creating the PE (Portable Executable) file (aka *.exe or *.dll) does its best to make sure all "objects" in assembly language are fully resolved. Among other things, this simplifies the design of the loader and linker, and it also makes it easier to design byte-code engineering lbiraries (BCELs) because all references are fully resolved. Thus, the number of invariants your code injection facilities must keep track of in a von Neumann-style block-structured language is kept to a minimum: stuff like branching and constants are the two main gotchas, and .NET simplifies management of constants by making changing them breaking changes. Branching correctly is tricky, and in fact trips up even smart people at MS Research, like the PeX team and anyone designing testing facilities that insert invariant-checks into code (possibly causing a short-branch optimization made by the compiler to become a broken invariant).
  MSIL also still provides things like using constructs to simplify human readibility and human typability but they matter not for static analysis. That's because, within a given module, all references are unambiguous. In fact, MSIL's ILAsm compiler will not compile ambiguous references.
  I forgot to mention that there is a name in computer science/software engineering for the classical problem of preserving invariants of an environment while modifying it. This is known as the Interposition Problem (although not that well known).
  This sounds like horizontal class modification, where you're adding new methods to existing class (call it A) as part of M, such that there is a new method. The question is how this new method is called:
  A a = myAFactory.make("...")
  a.m(parameter)
  ; or perhaps
  a.M::m(parameter)
  If my understanding of the question is correct, you'll be facing two cases:
  I think the best solution is to name the method with plain-old 'm', but to provide namespace conflict resolution facilities as another (wholly independent) language feature. That way, with namespace conflict (which will happen often for clients of independently developed modules), you just solve it as it appears - i.e. renaming N's m to 'm_from_n', and perhaps allowing order-of-import to determine default resolution.
  Why should this be non-OO, isn't OO all about proper encapsulation? If you have extension methods, ie methods defined in different modules than their class (often called monkey patching), it seems insane to not prefix them the module. How else do you tell apart two method of the same name but different semantics? Still, this is what Ruby and (to my best knowledge) all Smalltalk dialects do. Alas, I dont know about the state of this affair in other languages (with monkeys all the way down :) beyond these...