Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > how to stop the subclass from overriding a method.

Reply
Thread Tools

how to stop the subclass from overriding a method.

 
 
Venkat Akkineni
Guest
Posts: n/a
 
      07-30-2009
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/.

 
Reply With Quote
 
 
 
 
Matt Neuburg
Guest
Posts: n/a
 
      07-30-2009
Venkat Akkineni <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
Robert Dober
Guest
Posts: n/a
 
      07-30-2009
On Thu, Jul 30, 2009 at 9:00 PM, Matt Neuburg<(E-Mail Removed)> wro=
te:
> Venkat Akkineni <(E-Mail Removed)> 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

 
Reply With Quote
 
Tim Pease
Guest
Posts: n/a
 
      07-30-2009
On Thu, Jul 30, 2009 at 1:19 PM, Robert Dober<(E-Mail Removed)> wrote=
:
> On Thu, Jul 30, 2009 at 9:00 PM, Matt Neuburg<(E-Mail Removed)> w=

rote:
>> Venkat Akkineni <(E-Mail Removed)> 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

 
Reply With Quote
 
pharrington
Guest
Posts: n/a
 
      07-30-2009
On Jul 30, 3:26*pm, Tim Pease <(E-Mail Removed)> wrote:
> On Thu, Jul 30, 2009 at 1:19 PM, Robert Dober<(E-Mail Removed)> wrote:
> > On Thu, Jul 30, 2009 at 9:00 PM, Matt Neuburg<(E-Mail Removed)>wrote:
> >> Venkat Akkineni <(E-Mail Removed)> 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)
 
Reply With Quote
 
Venkat Akkineni
Guest
Posts: n/a
 
      07-30-2009
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/.

 
Reply With Quote
 
Venkat Akkineni
Guest
Posts: n/a
 
      07-30-2009
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/.

 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      07-31-2009
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/
 
Reply With Quote
 
Venkat Akkineni
Guest
Posts: n/a
 
      07-31-2009

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

 
Reply With Quote
 
Rick DeNatale
Guest
Posts: n/a
 
      07-31-2009
On Fri, Jul 31, 2009 at 7:59 AM, Venkat
Akkineni<(E-Mail Removed)> 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/pers...-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
Subclass of subclass Fab C++ 0 08-09-2012 09:54 AM
subclass a class in the namespace of the that subclass Trans Ruby 8 10-23-2008 07:24 AM
String subclass method returns subclass - bug or feature? S.Volkov Ruby 2 03-12-2006 06:46 PM
subclass has a variable that is subclass of same superclass jstorta Java 3 02-20-2006 08:42 PM



Advertisments