Dave Thomas writes: > Clemens Hintze <c.hintze / gmx.net> writes: > > > Both, the old terminology and your proposed one, it too much in the > > hidden internal direction, IMHO. I would call it for what it does, not > > how it work internally. > > I think that's a good point. Phrasing from the user's perspective, > rather than implementation, would be good. > > I quite like the idea of thinking about it as an object extension, but > even that has problems. What are we extending it with? > > def foo.bar end > > is also a kind of object extension. > > It's like we're subclassing the class of an object. How about > 'anonymous subclass'? > Hmmm... Why introducing the concept of a new class herein? From the users point of view, what is the difference between obj = Myclass.new class << obj def what print "Myclass\n"; end end and obj = Myclass.new def obj.what print "Myclass\n"; end ? I would say nothing, on the first glance! Both seems to be object extensions. So both could be named equivalent, or not? Why should we mention that it is done via anonym subclasses? Therefore I would call it something like object extension. A class extension would be: class Myclass def who print "here\n"; end end if Myclass already exists. > > > In the past there was a problem with the terms of iterators. matz has > > begun to clarify it, but perhaps there are some places where it is > > still inconsistent yet? It should be called either block (in source) > > or closure (as object) now. > > Wouldn't the object be a Proc object? Yes. Every closure is an instance of class Proc. A block, however, is only code surrounded by '{' and '}' or 'do' and 'end'. We can use 'lambda' or 'proc' or 'Proc.new' to convert a block to a closure (means Proc instance). Or we could use 'yield' to execute a block. I think this difference should be clear and consistent throughout all documentation, because it is a very important and flexible feature of Ruby. > > > Dave > \cle -- Clemens Hintze mailto: c.hintze / gmx.net