From: Lazaridis Ilias <ilias@...>
Date: 2011-07-07T05:26:15+09:00
Subject: [ruby-core:37832] [Ruby 1.9 - Bug #4893] Literal Instantiation breaks Object Model


Issue #4893 has been updated by Lazaridis Ilias.


Yukihiro Matsumoto wrote:
> |VARIABLE:
> |* I don't use *any* global variable (but an internal class-object scope variable)
> |* I use the same (string-)class-object scope flags that are used *excessively* within the existent ruby source-codes.
> 
> OK, you don't use the C global variable any longer.  But still uses
> global status, that I mean a line of 
> 
>   String.call_initialize=true
> 
> in anywhere in the program can change the whole behavior of whole
> program so much.  

This is really a (class)local status, see this issue subjecting terminology:

http://redmine.ruby-lang.org/issues/4984

> Comparing to other usage of global statuses (some of
> which I regret), influence of this change is too huge.

This change has a trivial influence, as nothing can go wrong. Even if the flag is set, this just means: the method-lookup will be used. The worst thing that can happen is, that you redefine initialize, and forget to set the flag.

See it otherwise:

You had good reasons to bypass the method-lookup by using the internal initialize method directly (resulted in higher execution speed).

Essentially you've introduced an invisible (class)local status, something like "String.speedy_initialize=true".

But if a user says: "I don't care about speed-loss, I want my redefined method to be called", then he must have access to this flag. That's a property of the class String, like any other one. This bit is nothing more than a simplified cache-mechanism, to speed-up the method-lookup. An internal implementation detail, bound to the class object.

> |At this point, if you still have objections, I ask you friendly to demonstrate them with test-code. This issue is far to deep to be handled with words.
> 
> Did you measured the performance?

I could not measure any speed difference with the call inactive (call_initialize=false), as it's minimal. Thus unused there's no difference.

With the call active, there is of course speed loss (100% and more), but I've already some ideas to reduce the speed loss. For this I need to wait some time, to be more secure with the internals.

In any way: the user who needs this feature should understand the speed issues.

----------------------------------------
Bug #4893: Literal Instantiation breaks Object Model
http://redmine.ruby-lang.org/issues/4893

Author: Lazaridis Ilias
Status: Rejected
Priority: Normal
Assignee: Yukihiro Matsumoto
Category: 
Target version: 
ruby -v: 1.9.2


#String2.rb 
class String 
  def initialize(val) 
    self.replace(val) 
    puts object_id 
  end 
  def my_method_test 
    'has method <my_method_test>' 
  end 
end 

# command line 
$ irb 
irb(main):001:0> original = String.new("original") 
=> "original" 
irb(main):002:0> load "String2.rb" 
=> true 
irb(main):003:0> altered = String.new("altered") 
21878604 
=> "altered" 
irb(main):004:0> altered.my_method_test 
=> "has method <my_method_test>" 
irb(main):005:0> literal = "literal" 
=> "literal" 
irb(main):006:0> literal.my_method_test 
=> "has method <my_method_test>" 
irb(main):007:0> 

- 

The initialize method is an integral part of the class String. 
From the moment that "String2.rb" is loaded, the initialize method of 
class String has been validly redefined. 

(The behaviour of the String class within the "irb session" is 
altered) 

The altered initialize method is now an integral part of the class 
String. 

The altered String object behaves as expected (responds to 
"my_method_test, initialized via redefined initialize method). 

The String(Literal) object responds to "my_method_test", but it is was 
not initialized with the redefined initialize method. 

- 

The "Literal Instantiation" calls the original (core-C-level) String 
initialize method instead of the redefined one (user-language-level). 
This *breaks* the object model. 





-- 
http://redmine.ruby-lang.org