From: Intransition Date: 2012-04-22T17:01:55+09:00 Subject: Re: Why must I know whether I extend a class or a module? ------=_Part_2693_30229675.1335081711094 Content-Type: multipart/alternative; boundary="----=_Part_2694_22495413.1335081711094" ------=_Part_2694_22495413.1335081711094 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Friday, April 20, 2012 11:15:50 PM UTC-4, Matthew Kerwin wrote: > > On 21/04/2012, Intransition wrote: > > > > > > On Friday, April 20, 2012 8:12:37 PM UTC-4, Matthew Kerwin wrote: > >> > >> On 20 April 2012 13:53, Intransition wrote: > >> > The forced distinction only serves to take that flexibility away from > >> > the > >> > programmer. > >> > >> Is there not overhead associated with that distinction? I haven't > >> actually looked into it, but I'd assume that Modules are a lot more > >> light-weight than Classes, because of the things that can't be done > >> with them. > >> > > The Class class is subclass of Module and is almost devoid of it's own > > methods. > > Fair enough. Must be a pragmatism issue then. Unless the cost of > discovering and defining constructors and initializers is somehow more > than we'd expect. > > What about multiple inheritance? Is/should it be valid to mix in a > class instead of a module? Actually, what happens right now if you > define a class with no initializer, and mix in a module that defines > __initialize ? > Well, it's funny you should ask. That has always been Matz' goto reason against the idea. He "hates" multiple inheritance and he sees this as such. I don't see it that way for a few reasons. Mainly b/c mixins already effectively serve the same purpose. In deed one could technically write all their code using modules. module Bar def self.new Class.new{ include Bar } end def initialize end end And yes, there is nothing stopping one from mixing in an #initialize method. > require 'myapp/adapters/core' > require 'myapp/adapters/foo' > require 'myapp/adapters/bar' > module MyApp::Adapters > # stuff that uses foo and bar > end > In the case myapp/adapters/core.rb is creating Adapters module. > > Even so, there are times when it doesn't really matter. If for instance > my > > MyApp::Adapters module had no contents other then the adapter classes, > then > > it really makes no difference. > > I guess I have a hole in my instinctive response for the right > approach to 'modules as a namespace', since I usually use them as > interfaces/multiple-inheritance/mixins. > I have considered forking Rubinius and implementing this --but I am not 100% sure how involved it would be. ------=_Part_2694_22495413.1335081711094 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Friday, April 20, 2012 11:15:50 PM UTC-4, Matthew Kerwin wrote:<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">On 21/04/2012, Intransition <= ;transfire@gmail.c= om> wrote:
>
>
> On Friday, April 20, 2012 8:12:37= PM UTC-4, Matthew Kerwin wrote:
>>
>> On 20 April 2012 1= 3:53, Intransition <transfire@gmail.com> wrote:
>> > The forced distinc= tion only serves to take that flexibility away from
>> > the>> > programmer.
>>
>> Is there not overhead as= sociated with that distinction? I haven't
>> actually looked into = it, but I'd assume that Modules are a lot more
>> light-weight tha= n Classes, because of the things that can't be done
>> with them.<= br>>>
> The Class class is subclass of Module and is almost dev= oid of it's own
> methods.

Fair enough. Must be a pragmatism issue = then. Unless the cost of
discovering and defining constructors and initi= alizers is somehow more
than we'd expect.

What about multiple inhe= ritance? Is/should it be valid to mix in a
class instead of a module? &n= bsp;Actually, what happens right now if you
define a class with no initi= alizer, and mix in a module that defines
__initialize ?

=
Well, it's funny you should ask. That has always been Matz'  goto= reason against the idea. He "hates" multiple inheritance and he sees this = as such. I don't see it that way for a few reasons. Mainly b/c mixins alrea= dy effectively serve the same purpose. In deed one could technically write = all their code using modules.

  module Bar
    def self.new
      Class.new= { include Bar }
    end
    def ini= tialize
    end
  end

And yes, there is nothing stopping one from mixing in an #initialize= method.
 

require 'myapp/adapters/core'
require 'myapp/adapters/foo'
r= equire 'myapp/adapters/bar'
module MyApp::Adapters
  # stuff tha= t uses foo and bar
end

In the case myapp/adapters/c= ore.rb is creating Adapters module.
 

> Even so, there are times when it doesn'= t really matter. If for instance my
> MyApp::Adapters module had no c= ontents other then the adapter classes, then
> it really makes no dif= ference.

I guess I have a hole in my instinctive response for the rig= ht
approach to 'modules as a namespace', since I usually use them as
= interfaces/multiple-inheritance/mixins.

I have co= nsidered forking Rubinius and implementing this --but I am not 100% sure ho= w involved it would be.
 
------=_Part_2694_22495413.1335081711094-- ------=_Part_2693_30229675.1335081711094--