[#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 Hodel <drbrain@...7.net>
Date: 2005-08-21 05:46:00 UTC
List: ruby-core #5597
On 20 Aug 2005, at 14:12, Eric Mahurin wrote:

> --- Eric Hodel <drbrain@segment7.net> wrote:
>
>> What happens when there is a bug in a 3rd-party library that
>> I want
>> to fix by overriding a method, but they've frozen it or made
>> it final?
>>
>
> That 3rd party library can already freeze the class right now.

While possible, I've never seen it used.

> They may do that for efficiency reasons in YARV or some other
> VM/complier.

Which YARV doesn't seem to take advantage of.

> Or they may have in-lined certain methods
> (possibly C) manually for performance reasons.

The way things work now, I can alias the method aside and fix it  
without jumping through hoops, whether it is from a C extension or if  
it is in Ruby itself.

> freezing a method is less restrictive than freezing a class.

I'd rather not encourage people to do things of questionable utility.

-- 
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04


In This Thread