From: Austin Ziegler <halostatue@...>
Date: 2005-07-28T03:02:40+09:00
Subject: Re: What's so special about operators, built-in classes and modules?

On 7/27/05, Daniel Brockman <daniel@brockman.se> wrote:> Austin Ziegler <halostatue@gmail.com> writes:>>> While the superficial and cosmetic difference between these two>>> almost completely equivalent concepts continue to mislead users,>>> do you still not see "in the least" any reason whatsoever to>>> unify them?>> Nope.> Then I'm forced to conclude that you are shying away from the> truth, as it is staring you in the face.
I'm not forcing you, either directly or indirectly (by my position).
I don't see any reason to unify the concepts behind classes andmodules. I see plenty of reasons to *not* do it (and Ara hasillustrated one). I see plenty of reasons to *improve* thedocumentation and explanations surrounding modules and how theywork, but none of these are an indication that the unification ofclasses and modules is a good idea in the least.
I'm not shying away from the truth; I'm just rejecting yourposition. There *is* a difference, you know.
>> I'll note that others have argued better in favour of this than>> you have and they're still not unified.> That's a new one � argument by pointing out that there are> better arguments in favor of the opposing side.
I'm not quite sure how you see that. 1) There *are* better arguments(with strong theoretical backing) for unification than what you'vesaid to date. Look for Mathieu's arguments on ruby-core. 2) Matz hasstill indicated that he's unconvinced. Therefore, 3) you have to doa much better job of arguing this case than Mathieu has done toconvince Matz.
If Matz is convinced, then I will also be convinced that theunification won't introduce more problems than it supposedly solves.
>> I think that unification would increase the confusion far MORE>> than what is currently present.> That is a reasonable belief. Indeed, I'm not completely> sure myself that unification would reduce net confusion.> So I'd be interested in seeing some arguments.
I believe that unification would increase net confusion. Modules asmixins are a simple, clean way of doing MI without hobbling oneselfthe way that Java has done with Interfaces. If you have analternative that doesn't lead down the path to the nightmare of C++MI, I'd love to hear it. Additionally, if modules and classes arethe same, then the existence of two keywords -- which will benecessary for historical reasons -- will itself introduce confusion.
> Here is an example of an argument:> > Whenever you bring up the issue of modules vs. classes, there will> generally be at least one person who believes that including a> module is the same as copying its body. This confusion would go> away if the two were unified.
Would it? I don't think so. It would seem to me that the confusionof:
  module Mod  end
  class Foo    include Mod  end
would not be reduced with:
  class Mod  end
  class Foo    include Mod  end
At least as far as "include" is concerned.
>>> class Module>>>   def new(*a, &b)>>>     const_defined?(:Viagra) or>>>     const_set(:Viagra, Class.new.include(self))>>>     const_get(:Viagra).new(*a, &b)>>>   end>>> end>> That's not instantiating a module. It's cute, but it's not>> instantiating a module.> Of course it's not instantiating a module, but it's pretty> much _as good as_ instantiating a module. It lets you use> modules instead of classes, which demonstrates that the> distinction is superficial.
Maybe you use modules differently, but while you can do somethinglike that, I still don't think that the difference between the twois simply a missing "new". Note that you're getting an automaticallocator and initializer in Class, but there's no allocators forModule objects.
-austin-- Austin Ziegler * halostatue@gmail.com               * Alternate: austin@halostatue.ca