How to stop the subclass from overriding a method

ruby-talk
1

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

···

--
Posted via http://www.ruby-forum.com/.

2

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.

···

Venkat Akkineni <venkatram.akkineni@gmail.com> wrote:

Hi

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

3

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

···

On Thu, Jul 30, 2009 at 9:00 PM, Matt Neuburg<matt_neuburg@tidbits.com> wrote:

Venkat Akkineni <venkatram.akkineni@gmail.com> wrote:

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*

4

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

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

···

On Thu, Jul 30, 2009 at 1:19 PM, Robert Dober<robert.dober@gmail.com> wrote:

On Thu, Jul 30, 2009 at 9:00 PM, Matt Neuburg<matt_neuburg@tidbits.com> wrote:

Venkat Akkineni <venkatram.akkineni@gmail.com> wrote:

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*

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.

5

>>> 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*
> 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

xeno@amrita:~/projects$ irb -rmonkey

class Test; def hello; puts "hello!"; end; end

=> nil

monkey_proof Test

=> Test

a = Test.new

=> #<Test:0x7f7c1db15008>

a.hello

hello!
=> nil

a.extend Enumerable

TypeError: can't modify frozen object
        from (irb):5:in `extend_object'
        from (irb):5:in `extend'
        from (irb):5

b = a.dup

=> #<Test:0x7f7c1dafb7c0>

b.extend Enumerable

=> #<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)

···

On Jul 30, 3:26 pm, Tim Pease <tim.pe...@gmail.com> wrote:

On Thu, Jul 30, 2009 at 1:19 PM, Robert Dober<robert.do...@gmail.com> wrote:
> On Thu, Jul 30, 2009 at 9:00 PM, Matt Neuburg<matt_neub...@tidbits.com> wrote:
>> Venkat Akkineni <venkatram.akkin...@gmail.com> wrote:

6

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

···

--
Posted via http://www.ruby-forum.com/.

7

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

···

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)

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

8

Very good article covering java's final keyword.

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

Venkat

···

--
Posted via http://www.ruby-forum.com/.

9

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

···

--
Posted via http://www.ruby-forum.com/\.

10

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.

···

On Fri, Jul 31, 2009 at 7:59 AM, Venkat Akkineni<venkatram.akkineni@gmail.com> wrote:

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 \-&gt; ruby

translation skills. The focus now is on how to implement the classes
better in ruby using the language features.

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

11

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.

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

···

On 31.07.2009 13:59, Venkat Akkineni wrote:

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

12

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.