[#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: TRANS <transfire@...>
Date: 2005-08-21 13:20:58 UTC
List: ruby-core #5604
On 8/21/05, Austin Ziegler <halostatue@gmail.com> wrote:
> No, it wouldn't be. Some of what I do would go away if rdoc gained
> attribute notation, but you'll sometimes see me do:
> 
>   attr_accessor :foo
>     # The ; is because of a vim limitation that I haven't bothered to
>     # find and fix yet.
>   remove_method :foo= ;
>   def foo=(f) #:nodoc:
>     ...
>   end
> 
> But the ability to change the meaning of a method after it's been
> initially defined *can* be useful, especially when you get to
> metaprogramming. Some of it might be solveable with AOP, but not all of
> it. The combination of AOP and subclassing is certainly insufficient to
> match the full power of method redefinition.

Not true.  The only thing you've saved in the above is possibly a
little memory. But more then likely you'll alias the old definition,
not remove it, and then you won't even save that. The common activity
of aliasing and redefining (and usually calling the old method within
it) is simply a very unDRY way to do an AOP-style wrap.

> > And remember you can still subclass and override. And if you really
> > have a lot of heavy changes to make, well, then its probably the right
> > time to get out the old Cut & Paste :-)
> 
> That sounds like someone trying to defend their pet idea more than
> someone who is being pragmatic.

No. See my response to Eric. Consider it from the other extreme: if
you redefine all but one method of a given class, then what was the
point?

T.


In This Thread