[#5563] Non-overridable and non-redefinable methods — Eric Mahurin <eric_mahurin@...>

Lately, I've been thinking about the future of ruby

44 messages 2005/08/19
[#5564] Re: Non-overridable and non-redefinable methods — Austin Ziegler <halostatue@...> 2005/08/19

On 8/19/05, Eric Mahurin <eric_mahurin@yahoo.com> wrote:

[#5571] Re: Non-overridable and non-redefinable methods — Eric Mahurin <eric_mahurin@...> 2005/08/19

--- Austin Ziegler <halostatue@gmail.com> wrote:

[#5574] Re: Non-overridable and non-redefinable methods — TRANS <transfire@...> 2005/08/20

Just wanted to add a few things.

[#5581] Re: Non-overridable and non-redefinable methods — Austin Ziegler <halostatue@...> 2005/08/20

On 8/19/05, TRANS <transfire@gmail.com> wrote:

[#5583] Re: Non-overridable and non-redefinable methods — "David A. Black" <dblack@...> 2005/08/20

Hi --

[#5585] Re: Non-overridable and non-redefinable methods — Eric Mahurin <eric_mahurin@...> 2005/08/20

--- "David A. Black" <dblack@wobblini.net> wrote:

[#5609] Pathname#walk for traversing path nodes (patch) — ES <ruby-ml@...>

Here is a small addition to Pathname against 1.9, probably suited

20 messages 2005/08/22

Re: Non-overridable and non-redefinable methods

From: Eric Mahurin <eric_mahurin@...>
Date: 2005-08-20 18:22:42 UTC
List: ruby-core #5585
--- "David A. Black" <dblack@wobblini.net> wrote:

> Hi --
> 
> On Sat, 20 Aug 2005, Austin Ziegler wrote:
> 
> > On 8/19/05, TRANS <transfire@gmail.com> wrote:
> >> Just wanted to add a few things.
> >>
> >> 1) If we get local instance methods, it might lessen the
> necessity,
> >> since they are not visible to the hierarchy chain, and
> thus can't be
> >> overridden. Granted it's not the same but it should
> alleviate some use
> >> cases.
> >
> > What do you mean by "local instance methods"?
> 
> I think that means:
> 
>    class C
>      def x
>        1
>      end
> 
>      localized :x   # or whatever
> 
>      def y
>        x
>      end
>    end
> 
>    class D < C
>      def x
>        2
>      end
>    end
> 
>    D.new.y     #  1 (because it calls the 'local' def. of x
> 
> or something like that.  I've probably misrepresented it
> slightly.

This would be a nice feature to have and would probably be a
better thing to use rather than "private", but I don't think it
really helps from an optimization standpoint.  I would assume
C#x could still be redefined at some point so you couldn't
easily inline it.

Using the same private/protected/public/localized way for
tagging methods, here is what I'm talking about:

class C
  def a; "a"; end

  # can't be redefined
  freeze_method :a 

  def b; "b"; end

  # can't be overriden in derived classes
  # should also imply that you can't redefine
  final :b 

end

class C
  # error - trying to redefine
  def a; "redefine-a"; end
  # error - trying to redefine
  def b; "redefine-c"; end
  # no problem
  def c; "add-c"; end 
end

class D < C
  # no problem - C#a is left in tact
  def a; "derived-a"; end
  # error - trying to override #b
  def b; "derived-b"; end
end

c = C.new

class << c
  # no problem - C#a is left in tact
  # we are operating on an anonymous meta class at this point
  # c effectively has a new class - its meta class
  def a; "meta-a"; end
  # error - trying to override #b
  # the meta class is a derived class of C
  def b; "meta-b"; end
end


Having the ability to prevent methods from being redefined is
really just a subset of what Class#freeze does.  Having the
ability to prevent methods from being overridden is new and at
least useful in a few methods in Object.




		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

In This Thread