From: Austin Ziegler Date: 2006-03-14T03:37:33+09:00 Subject: Re: abstract method in Ruby On 3/13/06, ara.t.howard@noaa.gov wrote:> On Tue, 14 Mar 2006, ilan berci wrote:>> A good portion of the GoF patterns rely on abstract methods (visitor,>> abstract factory, template method, etc... ) which IMO only shine in>> statically typed languages. It would be a shame to port all patterns>> (and their required prerequisite: abstract methods) simply because>> they are recognized in the static world and therefore would make a>> good fit in Ruby.>>>> The additional code needed for the ruby "abstract method" approach>> doesn't make the code any more readable. The extra LoC actually>> slows down the maintenance developer as she has to wade through more.> i disagree strongly here. check out these two snippets that i am> working on as we speak:>> def will_process_holding *a, &b> raise NotImplementedError> end> def process_holding *a, &b> raise NotImplementedError> end> def will_process_incoming(*a, &b)> raise NotImplementedError> end> def process_incoming(*a, &b)> raise NotImplementedError> end>> vs>> abstract_method "will_process_holding"> abstract_method "process_holding"> abstract_method "will_process_incoming"> abstract_method "process_incoming" Okay, Ara. Why do these methods need to be abstract and specificallyhave code around them? IMO, the *same* question should be asked oftsort.rb. I think that, in both cases, the answer is the same: theydon't. Adding a definition for an "abstract_method" really doesn't add*anything* to the readability of the code that a well-written comment(which *is* read by rdoc without modification) doesn't provide. [...] > sure - i could just go full on duck type - but good luck reading the> 2000 line satellite image processing library that requires these four> methods (and about 20 others) and trying to figure out which ones you> need to implement. i nice compact listing like this surely helps out> with that task doesn't it? I'm not sure. As I said earlier, PDF::Writer doesn't use them. Indevelopment versions of PDF::Writer, things like that have appeared --and promptly been removed because they add clutter, not clarity. [...]> now, all this starts out at about line 230. this is a little deep is> it not? i think it'd be great of rdoc understood and abstract_method> hook just like it now supports the 'attr_XXX' hooks but, even without> that, i'll take any hint i can get in code like this. > ask yourself this: why did the author not just rely on duck-typing?> why put these methods into the code at all? I ask, instead, how old tsort.rb is -- and that will generally indicatewhy it has defined abstract methods. >> In both solutions, an exception is thrown at runtime. The abstract>> method approach will not allow the developer to catch it any earlier>> than the duck typed default.> unless, using one approach it takes an hour to figure out which> methods to impliment and the other way it does not. Ara, this ignores the examples I gave early on: # All clients of this module must implement #each with no parameters. module Enum def map arr = [] each { |elem| arr << yield(elem) } arr end end I have just made #each an abstract method without adding any code atall. >> The exception proposed although slightly more readable will not in>> practice add any value as Ruby developers are used to seeing the>> exception and can narrow in on it expediently.> agreed. the point is to not get the exception in the first place> becausee the code was easier to understand how to hook into. And I disagree that it makes it easier to read, Ara. I don't write10,000 line programs, but PDF::Writer is 5,000 lines. Certain items,especially in current development versions, could *easily* have beendeclared as "abstract" (and would have to had been in static languages)but aren't necessary to do such in Ruby. > i really don't see why people would object to this idea. is it> because people are only writing 100 line programs in ruby that might> require one abstract method? i just don't understand how someone> could think that diving into a complex inheritence hierarchy of 30> classes/modules requiring 20 or so abstract methods would NOT be made> easier to grok if one could grep for /abstract_method/ in their editor> to get a jump on things... I really don't think that there's need for this in the core. I thinkthat the use of it is a crutch; with the programs you have to write,Ara, that might be necessary. (I've used similar crutches in someversions of PDF::Writer experiments.) -austin--Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca