From: Rick DeNatale on
On Sat, Feb 13, 2010 at 5:27 AM, Ryan Davis <ryand-ruby(a)zenspider.com> wrote:
>
> On Feb 13, 2010, at 00:42 , Michel Demazure wrote:
>
>> Modules are
>> not really objects ("everything is an object", they say), but a way to
>> assign methods to objects "from outside".
>
> how are modules not objects? do they not have state? do they not have behavior? are they not instances of a class?

If you prick them, do they not bleed? <G>

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

From: Colin Bartlett on
On Sat, Feb 13, 2010 at 1:40 PM, Rick DeNatale <rick.denatale(a)gmail.com> wrote:
> On Sat, Feb 13, 2010 at 5:27 AM, Ryan Davis <ryand-ruby(a)zenspider.com> wrote:
>>
>> On Feb 13, 2010, at 00:42 , Michel Demazure wrote:
>>
>>> Modules are
>>> not really objects ("everything is an object", they say), but a way to
>>> assign methods to objects "from outside".
>>
>> how are modules not objects? do they not have state? do they not have behavior? are they not instances of a class?
>
> If you prick them, do they not bleed? <G>
>
> --
> Rick DeNatale

I just read Rick's one-liner sitting - appropriately - in the cafe/bar
of the ICA (Institute of Contemporary Arts) in London, and it's made
my afternoon, even if I don't get to see the Japanese film for which
I'm third on a waiting list!

From: David Masover on
On Friday 12 February 2010 06:00:06 pm Jörg W Mittag wrote:
> Unfortunately, for this dynamic role injection stuff, we run into one
> of the (very few) limitations of Ruby. We cannot just, as Trygve says,
> "subclass the compiler"

That's true, although the suggestion that we do so made me a bit
uncomfortable. If you're right, I'll have to actually see a language that
implements this in order to get it, if I get it even then.

But probably the most important property Ruby has is that it's easy to
implement things that look like new syntax, but don't actually involve
touching the parser at all.

> and "add to and delete methods from the method
> dictionary" in Ruby

Sure we can! We have define_method, remove_method, undef_method,
UnboundMethod, and metaclasses. Where's the problem?

> subvert the compiler like
> James's C++ template metaprogramming implementation does.

I guess it depends how much you want to do, but we also have methods which can
accept blocks, which makes it very easy to create DSLs. We can also define
methods on classes, or even on Class itself. Whether you consider this
"subversion" is a matter of semantics, but I didn't really see anything in the
talk that looked impossible, except maybe the graphical representation.

> the leaky
> abstraction of ECMAScript actually *helps* rather than hurts.

I doubt it. I think what's much more useful is that ECMAScript has prototypal
inheritance. If you're talking about the fact that I can "steal" a method from
one class and apply it to another, there is only one thing stopping this in
Ruby, and it's some anal-retentive type-safety thing probably leftover from
Java or C++ -- the fact that you can't bind an UnboundMethod to anything
that's not either a direct class or a subclass of the class that UnboundMethod
was originally defined on.

Which just means that we can either deal purely in blocks/procs, or we can
define "roles" as UnboundMethods on Object.

Now, I'll grant this kind of composition is much _easier_ in ECMAScript, in
that we can easily rebind methods, pass them around as arguments, and assign
them directly to objects using the [] notation. However, just about all the
same tools exist in Ruby, they're just clumsier to use.

From: Caleb Clausen on
On 2/12/10, Jörg W Mittag <JoergWMittag+Ruby(a)googlemail.com> wrote:
> Unfortunately, for this dynamic role injection stuff, we run into one
> of the (very few) limitations of Ruby. We cannot just, as Trygve says,
> "subclass the compiler" and "add to and delete methods from the method
> dictionary" in Ruby (although we probably *can* in Rubinius) like
> Trygve's Squeak implementation does or subvert the compiler like
> James's C++ template metaprogramming implementation does.

When people say things like this, it makes me think there ought to be
a way to do it by using RubyMacros. So, I tried to rewrite Tom/Brian's
code as macros... I think I can get rid of the need to call extend or
use method_missing/proxies. But I had to use a feature of RubyMacros
that I haven't invented yet (motivation!) and I may be missing the
point (esp as I didn't watch the movie). Since I don't know if it
would even work, I'm reluctant to post the example I came up with,,,
but if anyone really wants to see it, I will.

From: Intransition on
On Feb 15, 4:24 am, Caleb Clausen <vikk...(a)gmail.com> wrote:

> When people say things like this, it makes me think there ought to be
> a way to do it by using RubyMacros. So, I tried to rewrite Tom/Brian's
> code as macros... I think I can get rid of the need to call extend or
> use method_missing/proxies. But I had to use a feature of RubyMacros
> that I haven't invented yet (motivation!) and I may be missing the
> point (esp as I didn't watch the movie). Since I don't know if it
> would even work, I'm reluctant to post the example I came up with,,,
> but if anyone really wants to see it, I will.

Personally I think Mr. Mittag is overstating the issue. I haven't seen
anything yet to indicate that DCI is beyond implementation in regular
Ruby. But then maybe I am misunderstanding some key elements --I would
love to know. In any case, feel free to show us your code, even if it
is just an exercise in what can be done with RubyMacros.