how to stop the subclass from overriding a method.

Discussion in 'Ruby' started by Venkat Akkineni, Jul 30, 2009.

  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/.
    Venkat Akkineni, Jul 30, 2009
    #1
    1. Advertising

  2. Venkat Akkineni

    Matt Neuburg Guest

    Venkat Akkineni <> 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* can prevent the programmer from working his will
    (even "private" can be worked around, for example), so the warning seems
    a reasonable approach.

    m.
    Matt Neuburg, Jul 30, 2009
    #2
    1. Advertising

  3. Venkat Akkineni

    Robert Dober Guest

    On Thu, Jul 30, 2009 at 9:00 PM, Matt Neuburg<> wro=
    te:
    > Venkat Akkineni <> wrote:
    >
    >> Hi
    >>
    >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 How would one create a method that is access=

    ible from
    >> outside but avoid the subclass from overriding and changing the
    >> definition?

    >
    > 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
    Robert Dober, Jul 30, 2009
    #3
  4. Venkat Akkineni

    Tim Pease Guest

    On Thu, Jul 30, 2009 at 1:19 PM, Robert Dober<> wrote=
    :
    > On Thu, Jul 30, 2009 at 9:00 PM, Matt Neuburg<> w=

    rote:
    >> Venkat Akkineni <> wrote:
    >>
    >>> Hi
    >>>
    >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 How would one create a method that is acces=

    sible from
    >>> outside but avoid the subclass from overriding and changing the
    >>> definition?

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


    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
    Tim Pease, Jul 30, 2009
    #4
  5. Venkat Akkineni

    pharrington Guest

    On Jul 30, 3:26 pm, Tim Pease <> wrote:
    > On Thu, Jul 30, 2009 at 1:19 PM, Robert Dober<> wrote:
    > > On Thu, Jul 30, 2009 at 9:00 PM, Matt Neuburg<>wrote:
    > >> Venkat Akkineni <> 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.

    >
    > 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)
    pharrington, Jul 30, 2009
    #5
  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/.
    Venkat Akkineni, Jul 30, 2009
    #6
  7. Venkat Akkineni, Jul 30, 2009
    #7
  8. 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/
    Robert Klemme, Jul 31, 2009
    #8

  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/.
    Venkat Akkineni, Jul 31, 2009
    #9
  10. On Fri, Jul 31, 2009 at 7:59 AM, Venkat
    Akkineni<> 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. =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
    Rick DeNatale, Jul 31, 2009
    #10
  11. Venkat Akkineni

    Gary Yngve Guest

    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.
    Gary Yngve, Jul 31, 2009
    #11
  12. On 31.07.2009 13:59, Venkat Akkineni 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.


    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

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
    Robert Klemme, Aug 1, 2009
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jstorta
    Replies:
    3
    Views:
    437
    jstorta
    Feb 20, 2006
  2. Zac Burns
    Replies:
    16
    Views:
    512
    Arnaud Delobelle
    Dec 5, 2008
  3. S.Volkov
    Replies:
    2
    Views:
    213
    S.Volkov
    Mar 12, 2006
  4. Trans
    Replies:
    8
    Views:
    320
    Robert Klemme
    Oct 23, 2008
  5. Fab

    Subclass of subclass

    Fab, Aug 9, 2012, in forum: C++
    Replies:
    0
    Views:
    394
Loading...

Share This Page