From: Intransition <transfire@...>
Date: 2012-04-23T01:45:29+09:00
Subject: Re: Why must I know whether I extend a class or a module?

------=_Part_1145_262848.1335113126389
Content-Type: multipart/alternative; 
	boundary="----=_Part_1146_22064412.1335113126389"

------=_Part_1146_22064412.1335113126389
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit



On Sunday, April 22, 2012 9:01:53 AM UTC-4, Matthew Kerwin wrote:
>
> On 22 April 2012 18:01, Intransition <transfire@gmail.com> wrote:
> > 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.
>
> That's ... absurd; the 'include' statement is the paragon of multiple
> inheritance.  I always thought that the search path from class to
> modules to superclass and so on was a brilliant solution to such a
> frequently murky and messy topic.
>
> My worldview is somewhat shaken now.
>

Pretty much my sentiments exactly.
 

> >> 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.
>
> I'm sorry, implementing what, precisely?
>
Basically:

1) Allow classes to be included.
2) Allow modules to be instantiated.
3) Allow module's class-methods to be "inherited" just like class' 
class-methods.

This would effectively make classes and modules exactly same.

Also,

4) Auto-instantiate namespaces.
5) Make toplevel a self extended module that doesn't infect all objects.


------=_Part_1146_22064412.1335113126389
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, April 22, 2012 9:01:53 AM UTC-4, Matthew Kerwin wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On 22 April 2012 18:01, Intransi=
tion &lt;<a href=3D"mailto:transfire@gmail.com" target=3D"_blank">transfire=
@gmail.com</a>&gt; wrote:<br>&gt; Well, it's funny you should ask. That has=
 always been Matz' &nbsp;goto reason<br>&gt; against the idea. He "hates" m=
ultiple inheritance and he sees this as such.<p>That's ... absurd; the 'inc=
lude' statement is the paragon of multiple<br>inheritance. &nbsp;I always t=
hought that the search path from class to<br>modules to superclass and so o=
n was a brilliant solution to such a<br>frequently murky and messy topic.</=
p><p>My worldview is somewhat shaken now.</p></blockquote><div><br></div><d=
iv>Pretty much my sentiments exactly.<br></div><div>&nbsp;</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><p>&gt;&gt; I guess I have a hole in my i=
nstinctive response for the right<br>&gt;&gt; approach to 'modules as a nam=
espace', since I usually use them as<br>&gt;&gt; interfaces/multiple-<wbr>i=
nheritance/mixins.<br>&gt;<br>&gt; I have considered forking Rubinius and i=
mplementing this --but I am not 100%<br>&gt; sure how involved it would be.=
</p><p>I'm sorry, implementing what, precisely?</p></blockquote><div>Basica=
lly:</div><div><br></div><div>1) Allow classes to be included.</div><div>2)=
 Allow modules to be instantiated.</div><div>3) Allow module's class-method=
s to be "inherited" just like class' class-methods.</div><div><br></div><di=
v>This would effectively make classes and modules exactly same.</div><div><=
br></div><div>Also,</div><div><br></div><div>4) Auto-instantiate namespaces=
.<br></div><div>5) Make toplevel a self extended module that doesn't infect=
 all objects.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><p></p><p></p><p></p><p></p><p></p><p></p><p></p></blockquote>
------=_Part_1146_22064412.1335113126389--

------=_Part_1145_262848.1335113126389--