[ruby-core:37915] [Ruby 1.9 - Bug #4893] Literal Instantiation breaks Object Model

Issue #4893 has been updated by Lazaridis Ilias.


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

Commented there.
 
> |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".

Different criteria, possibly. 
* I "hate" that the current 1.9.2 does not call a redefined initialize at all. 
* It would be ok if 1.9.x would not call a redefined initialize, because I forgot to set the flag.

Anyway, this is an implementation detail. If you really hate this, the flag could become invisible to the user (automated setting).

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

Based on your reasoning, you should remove the "RUBY_EVENT_*" mechanism, as it can be "used deeply inside a third party library", decreasing the *overall* speed of the interpreter. 

The object-model allows Classes to be "reopened", even the classes from the build-in types. This can be "used deeply inside a third party library" to reduce the speed of the overall language. Thus you should drop the whole object-model, too?

Anyway, I understand your reasoning, and I would possibly agree, if this issue would be a "feature request".

It's not. This issue is about to make the interpreter feature-complete, to remove a limitation of the implementation.

The mentioned speed loss for this issue is for a naked literal-instantiation within a loop, not for a natural application. The method-lookup alone costs 35% (if I measured correct). 

In other words: the flag would become redundant, if you would say: "Ok, we do the method-lookup, at the speed-cost of 35%, being this way consistent with the object-model". 35% is much speed, an thus, I introduced the flag.

> That is the very reason I recommend you to fork the language off from
> Ruby.  Don't bother us.

If I had a goal: increase throughput of web-applications by 100%, then I would make a fork, because that would mean to do an overall refactoring / rework and a partial reimplementation.

But here I really just want to remove a small limitation of the current implementation.

> By the way, I have noticed that your patch invokes initialize with the
> receiver itself, which is not yet initialized, as an argument.

Please look again at the code. It is initialized.

I've not removed the existent low-level initialization. The object is internally initialized, and is passed to the redefined initialized method for further processing/initialization. This way I didn't need to create a temporal internal string object. 

An implementation detail, which can be changed (although it seems not necessary).

> That
> makes me feel weird.  That might satisfy your particular requirement,
> but I don't consider it consistent as you claim.

It's more consistent than the existent implementation, and it passes the test-all.

And you should know that providing full consistency would need a rework/refactoring of the string.c and other code units (removed duplicated code, clarify structure, ...). 

In other words: the current implementation is not consistent. Adding one missing feature (this issue) cannot make it consistent.

.




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