From: Yukihiro Matsumoto <matz@...>
Date: 2011-07-07T07:51:29+09:00
Subject: [ruby-core:37836] [Ruby 1.9 - Bug #4893] Literal Instantiation breaks Object Model


Issue #4893 has been updated by Yukihiro Matsumoto.


|This is really a (class)local status, see this issue subjecting terminology:
|
|http://redmine.ruby-lang.org/issues/4984

I am sorry but I don't understand what you mean by issue #4984.  Both
global status and local status has String.call_initialize in examples.

Class objects can be accessed from everywhere.  A modifiable attribute
of a globally accessible object is global status, in my terminology.

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

I understand you have different criteria from me.  At least, I hate
that "worst case".

|> Did you measure 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.

Thus adding one thing to worry to the language performance?  Once the
feature added, that could be "abused" beyond your expectation.  What
if that feature is used deep inside of the third party library?
People would blame not only the author of the library, but the
language and me for decreasing performance.  I am not ready nor
enthusiastic to accept that kind of complains for this particular
feature.

But Ilias, you are safe.  Since no one cares who proposed the feature.
That is the very reason I recommend you to fork the language off from
Ruby.  Don't bother us.

By the way, I have noticed that your patch invokes initialize with the
receiver itself, which is not yet initialized, as an argument.  That
makes me feel weird.  That might satisfy your particular requirement,
but I don't consider it consistent as you claim.

							matz.

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