how to stop the subclass from overriding a method.

[Venkat Akkineni]

Hi

How would one create a method that is accessible from
outside but avoid the subclass from overriding and changing the
definition?

I could declare the private block but this would will not
provide the method to be accessed from outside.

Thanks
Venkat

 

[Matt Neuburg]

Hi

How would one create a method that is accessible from
outside but avoid the subclass from overriding and changing the
definition?

Something like this?

class Superclass
def do_not_override
end
def self.method_added(s)
if s == :do_not_override
puts "Warning: you should not override this method"
else super
end
end
end

That doesn't really prevent the programmer from working his will, but
then in Ruby *nothing* can prevent the programmer from working his will
(even "private" can be worked around, for example), so the warning seems
a reasonable approach.

m.

 

[Robert Dober]

Something like this?

class Superclass
=A0def do_not_override
=A0end
=A0def self.method_added(s)
=A0 =A0if s =3D=3D :do_not_override
=A0 =A0 =A0puts "Warning: you should not override this method"
=A0 =A0else super
=A0 =A0end
=A0end
end

That doesn't really prevent the programmer from working his will, but
then in Ruby *nothing*

with the exception of freeze, but that is not applicable here as
frozen classes can be subclassed without any problem and would be too
radical anyway.
But I thought if noteworthy that frozen objects and closures cannot be
"cracked" in Ruby.
Cheers
Robert

 

[Tim Pease]

with the exception of freeze, but that is not applicable here as
frozen classes can be subclassed without any problem and would be too
radical anyway.
But I thought if noteworthy that frozen objects and closures cannot be
"cracked" in Ruby.

An interesting little experiment I played a while ago regarding frozen
classes and modules.

http://gist.github.com/82025

Does not address the original poster's question, but it might spur
some other creative thinking. One addition to this gist would be the
creation of an "inherited" method in the frozen class that would
subsequently freeze any class that tries to inherit from this.
Essentially this would make the class "un-inheritable" since
subclasses should not define any new methods.

Blessings,
TwP

 

[pharrington]

An interesting little experiment I played a while ago regarding frozen
classes and modules.

http://gist.github.com/82025

Does not address the original poster's question, but it might spur
some other creative thinking. One addition to this gist would be the
creation of an "inherited" method in the frozen class that would
subsequently freeze any class that tries to inherit from this.
Essentially this would make the class "un-inheritable" since
subclasses should not define any new methods.

Blessings,
TwP

xeno@amrita:~/projects$ irb -rmonkeyhello!
=> nilTypeError: can't modify frozen object
from (irb):5:in `extend_object'
from (irb):5:in `extend'
from (irb):5=> #<Test:0x7f7c1dafb7c0>

:\

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)

 

[Venkat Akkineni]

It makes more sense in java. Let me prove my point with an example.

public final String format (Object obj) {
return format(obj, new StringBuffer (), new FieldPosition
(0)).toString();
}

public abstract StringBuffer format(Object obj,
StringBuffer toAppendTo,
FieldPosition pos);

Java doesn't provide the faicility of multiple arguments. Hence one will
have to resort to method overloading. But, all the first method is doing
is create two objects and calling the second method. Hence there is no
point in leaving this method free to be played around with.

Also I believe in the web programming arena security concerns
necessitate the surity that coe won't be dynamically changed.

Hope I am not preaching the prophet.

Venkat

 

[Venkat Akkineni]

Very good article covering java's final keyword.

http://renaud.waldura.com/doc/java/final-keyword.shtml

Venkat

 

[Robert Klemme]

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

 

[Venkat Akkineni]

It will certainly work but you'll end up with Java written
with Ruby syntax.

This was playing in the back of my head. But makes more sense when
detailed from another person's perspective. A sensible argument one
would expect from purists.

Hence I have given up trying perfect my java -> ruby
translation skills. The focus now is on how to implement the classes
better in ruby using the language features. The price is time which we
have agreed on paying. We could do the API from the scratch but feel
that would consume a lot of time in requirements analysis itself let
alone development and testing.

Thanks
Venkat

 

[Rick DeNatale]

This was playing in the back of my head. But makes more sense when
detailed from another person's perspective. =A0A sensible argument one
would expect from purists.

=A0 =A0 =A0 =A0 =A0Hence I have given up trying perfect my java -> ruby
translation skills. The focus now is on how to implement the classes
better in ruby using the language features.

This is a good move, and the right thing to do. Some things just
don't transfer between languages.

An analogy might be a native French speaker learning English trying to
hang on to the idea that adjectives need to agree in gender with the
nouns they modify, or an English speaker learning French insisting
that the adjectives almost always go before the noun, rather than the
other way around.


--=20
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

 

[Gary Yngve]

Are you trying to prevent overriding a method from the security
standpoint or the software engg standpoint?

If the latter, you can use rspec to code tests that fail if certain
methods have been overridden.

 

[Robert Klemme]

This was playing in the back of my head. But makes more sense when
detailed from another person's perspective. A sensible argument one
would expect from purists.

I am not sure I qualify as purist. I just tried to step back and think
about what the consequences of your endeavor would be.

Hence I have given up trying perfect my java -> ruby
translation skills. The focus now is on how to implement the classes
better in ruby using the language features. The price is time which we
have agreed on paying. We could do the API from the scratch but feel
that would consume a lot of time in requirements analysis itself let
alone development and testing.

What you can do IMHO is look at the original Java design to find out
which tasks have to be done and how the code is structured. Chances are
that you will find more important and well designed Java classes also in
your Ruby version. That way you at least have a mental framework which
surely helps in redeveloping the application in Ruby. So you are
actually only throwing code away but not ideas - and these seem to be
much more important.

Kind regards

robert