From: Robert Klemme <shortcutter@...>
Date: 2009-07-31T19:20:05+09:00
Subject: Re: how to stop the subclass from overriding a method.

On 30.07.2009 23:35, pharrington wrote:

> I do wonder though; maybe I've just had my head buried in Ruby too
> much these days, but in general, exactly what *is* the point of trying
> to restrict modification of your libraries? I understand 'private' and
> ish as a "hey, you probably don't have any reason to call me :\" sort
> of thing, but what does the library writer gain from trying to ensure
> their code won't be dynamically changed? Does this mostly just play
> into larger systems where your library is (or is part of) a larger
> framework, and as a curtesy you want to ensure that others parts of
> the system don't change you to avoid confusion? (if so, i apologize
> for the silly .dup jab there)

Making methods final makes sense if you apply the template method 
pattern in an abstract class (another thing which does not have a direct 
translation in Ruby but might be mimicked with modules).  You make the 
template method final (i.e. non overridable) and call abstract methods 
or overridable methods from the template method.  Then, subclasses can 
and must override those other methods but the overall algorithm remains 
fixed.  Actually Venkat's example is such a case.

What I start wondering is this: is the direct translation of a Java 
project into Ruby the way that Venkat seems to attempt a reasonable 
thing to do?  It will certainly work but you'll end up with Java written 
with Ruby syntax.  This has some consequences, for example, you are 
usually not using some of Ruby's core features.  And the resulting code 
might not blend well with existing other Ruby libraries.

For example, while of course you can use the template method pattern in 
Ruby, sometimes a method which uses a block works as well and is 
certainly more idiomatic.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/