"Code must be Chunkable"
in [Ruby]
|
From: Rick DeNatale on 13 Feb 2010 08:40 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 13 Feb 2010 10:00 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 13 Feb 2010 13:07 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 15 Feb 2010 04:24 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 15 Feb 2010 07:44
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. |