From: Robert Klemme Date: 2010-06-25T00:58:42+09:00 Subject: Re: Namespacing a class 2010/6/24 Intransition : > > > On Jun 24, 6:48 am, Robert Klemme wrote: > >> I believe the more important point is that - although classes and >> modules have only few differences (inheritance, instance creation) - >> they are deliberately kept separate because they are language >> artifacts intended to model different concepts (entities vs. >> behavior).  Even if it is technically possible to mix in classes the >> same way as modules (and I believe Jörg's assessment is correct here) >> it probably does not make much sense to allow this from a conceptual >> point of view. > > I disagree. This sort of explanation has no material bases --how does > the conceptual distinction help us? I think it hurts us for a few > reasons. > > 1) It disrupts auto-creation of namespaces. E.g. > >  class Y::X >  end > > What is Y, a class or module? Because of the distinction between class > and module you have to pre-define it. This futher leads to "bottom > requiring" --using require at the bottom of scripts instead of at the > top. I don't understand what you mean here. Can you elaborate or provide an example? > 2) The developer is forced to choose between two arbitrarily limited > mechanisms for modeling behavior. Classes can only re-used once per > subclass and not at all via modules. Modules can be reused extensively > but do not naturally include their singleton methods. These > limitations lead to a number of code smells from overly limited use of > inheritance to included/ClassMethods hooks. Why is not including their singleton methods a strong limitation? > 3) Using tools for conceptually different cases does not require that > their be physically different tools for each case. I wrench is just as > good for tightening a nut as it is for loosening one. If I had to use > two separate tools it would be quite annoying. I believe this is a bad analogy. If at all you would have to take "tightening and loosing nuts" and "hammering". In that case it's quite obvious that you would not normally use the same tool for the job. > Following your conceptual distinction argument we could just as easily > argue for separate entities for mixins and namespaces  since those are > also different uses of modules. Clearly no one wants that. Actually I thought about mentioning this because namespacing is yet another concept which happens to have two tools - module and class. It probably feels very natural because all major OO languages do support this. And it does have some merits. > I have never heard of a solid reason for the division between classes > and modules --my guess is that there is no real reason other than that > it how it was done originally, and changing it now means 1) a major > version bump and 2) an overhaul of the implementation. I find that distinction pretty clear as I have tried to point out earlier. Somehow you seem to be using the language quite differently than me and have run into limitations that do not exist for me. Maybe we can take the discussion a bit further to find out more about this. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/