https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112011-06-17T01:13:43ZRuby Issue Tracking SystemRuby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=180122011-06-17T01:13:43Znaruse (Yui NARUSE)naruse@airemix.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><p>It's a limitation of current Ruby, not a bug at least.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=180132011-06-17T01:23:10Zjudofyr (Magnus Holm)judofyr@gmail.com
<ul></ul><p>How exactly do you expect this to work? If the string literal is supposed to<br>
be created with String.new(), what do we pass to String.new()? If we pass a<br>
simple string (that is, a string which hasn't gone through String.new()),<br>
these two behave different:</p>
<p>"Hello World" # => Calls String.new() with a simple string and returns a<br>
full string<br>
String.new("Hello World") # => Calls String.new() with string literal (a<br>
full string) and returns a full string</p>
<p>Beside, I don't see how this breaks the object model. The object model<br>
doesn't state that all created strings must be created through String.new.<br>
In fact, it's possible to side-step the initialization in pure Ruby<br>
too: String.allocate.replace("Hello").</p>
<p>// Magnus Holm</p>
<p>On Thu, Jun 16, 2011 at 17:46, Lazaridis Ilias <a href="mailto:ilias@lazaridis.com" class="email">ilias@lazaridis.com</a> wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Literal Instantiation breaks Object Model (Rejected)" href="https://bugs.ruby-lang.org/issues/4893">#4893</a> has been reported by Lazaridis Ilias.</p>
<hr>
<p>Bug <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Literal Instantiation breaks Object Model (Rejected)" href="https://bugs.ruby-lang.org/issues/4893">#4893</a>: Literal Instantiation breaks Object Model<br>
<a href="http://redmine.ruby-lang.org/issues/4893" class="external">http://redmine.ruby-lang.org/issues/4893</a></p>
<p>Author: Lazaridis Ilias<br>
Status: Open<br>
Priority: Normal<br>
Assignee:<br>
Category:<br>
Target version:<br>
ruby -v: 1.9.2</p>
<p>#String2.rb<br>
class String<br>
def initialize(val)<br>
self.replace(val)<br>
puts object_id<br>
end<br>
def my_method_test<br>
'has method <my_method_test>'<br>
end<br>
end</p>
<a name="command-line"></a>
<h1 >command line<a href="#command-line" class="wiki-anchor">¶</a></h1>
<p>$ irb<br>
irb(main):001:0> original = String.new("original")<br>
=> "original"<br>
irb(main):002:0> load "String2.rb"<br>
=> true<br>
irb(main):003:0> altered = String.new("altered")<br>
21878604<br>
=> "altered"<br>
irb(main):004:0> altered.my_method_test<br>
=> "has method <my_method_test>"<br>
irb(main):005:0> literal = "literal"<br>
=> "literal"<br>
irb(main):006:0> literal.my_method_test<br>
=> "has method <my_method_test>"<br>
irb(main):007:0></p>
<ul>
<li>
</ul>
<p>The initialize method is an integral part of the class String.<br>
From the moment that "String2.rb" is loaded, the initialize method of<br>
class String has been validly redefined.</p>
<p>(The behaviour of the String class within the "irb session" is<br>
altered)</p>
<p>The altered initialize method is now an integral part of the class<br>
String.</p>
<p>The altered String object behaves as expected (responds to<br>
"my_method_test, initialized via redefined initialize method).</p>
<p>The String(Literal) object responds to "my_method_test", but it is was<br>
not initialized with the redefined initialize method.</p>
<ul>
<li>
</ul>
<p>The "Literal Instantiation" calls the original (core-C-level) String<br>
initialize method instead of the redefined one (user-language-level).<br>
This <em>breaks</em> the object model.</p>
<p>--<br>
<a href="http://redmine.ruby-lang.org" class="external">http://redmine.ruby-lang.org</a></p>
</blockquote> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=180162011-06-17T01:42:25Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Magnus Holm wrote:</p>
<blockquote>
<p>How exactly do you expect this to work? If the string literal is supposed to<br>
[...] - (off context)</p>
</blockquote>
<p>You should reread the description, experiment a little, and take some time to respond.</p>
<p>And please, if possible, remove the quoted message from your reply on the issue tracking system.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=180172011-06-17T01:45:11Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Yui NARUSE wrote:</p>
<blockquote>
<p>It's a limitation of current Ruby, not a bug at least.</p>
</blockquote>
<p>From my point of view, it's a defect/bug, but I wan't argue.</p>
<p>If you think that's an "limitation" (instead of a bug), then there <em>is</em> an issue (and thus you should not "reject" this issue).</p>
<p>You could add an issue type "Limitation".</p>
<p>I any way, rejecting the issue does not change that there <em>is</em> an issue with the literal-instantiation.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=180182011-06-17T01:53:09Zrkh (Konstantin Haase)me@rkh.im
<ul></ul><p>On Jun 16, 2011, at 18:42 , Lazaridis Ilias wrote:</p>
<blockquote>
<p>You should reread the description, experiment a little, and take some time to respond.</p>
</blockquote>
<p>To rephrase what Magnus said:<br>
Where does the object passed to initialize come from? How has that object been initialized?</p>
<p>Konstantin</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=180192011-06-17T02:00:43Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Rejected</i> to <i>Feedback</i></li></ul><p>Post a patch to fix it.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=180222011-06-17T02:23:06Zjudofyr (Magnus Holm)judofyr@gmail.com
<ul></ul><blockquote>
<p>You should reread the description, experiment a little, and take some time to respond.</p>
</blockquote>
<p>I'm not even sure what you want to accomplish with this issue. You<br>
provide some code that you think should behave differently, but you<br>
don't provide any solutions. I thought you wanted to change the<br>
behavior, so I described one simple solution and the issues with it.<br>
Do you have another way to solve this?</p>
<blockquote>
<p>From my point of view, it's a defect/bug, but I wan't argue.</p>
</blockquote>
<p>Yes, but matz is the boss here. From his point of view, this is<br>
expected behavior.</p>
<blockquote>
<p>If you think that's an "limitation" (instead of a bug), then there <em>is</em> an issue (and thus you should not "reject" this issue).</p>
</blockquote>
<p>The fact that something is a limitation doesn't mean that it's an<br>
issue. Ruby can't spawn magical unicorn (a limitation), but it's not<br>
an issue. "Rejected" in the issue tracker means "We won't try to fix<br>
it". They won't try to change this limitation, therefore they reject<br>
it.</p>
<blockquote>
<p>I any way, rejecting the issue does not change that there <em>is</em> an issue with the literal-instantiation.</p>
</blockquote>
<p>Issues like these are subjective. <em>You</em> have an issue with the<br>
literal-instantiation, while matz does not (see ruby-talk).</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=180232011-06-17T02:32:59Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Shyouhei Urabe wrote:</p>
<blockquote>
<p>Post a patch to fix it.</p>
</blockquote>
<p>Maybe I'll do so.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=180242011-06-17T04:00:30Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Konstantin Haase wrote:</p>
<blockquote>
<p>On Jun 16, 2011, at 18:42 , Lazaridis Ilias wrote:</p>
<blockquote>
<p>You should reread the description, experiment a little, and take some time to respond.</p>
</blockquote>
<p>To rephrase what Magnus said:<br>
Where does the object passed to initialize come from? How has that object been initialized?</p>
</blockquote>
<p>"How has that 'uninitialized object' been allocated?" would be the question.</p>
<p>String#allocate (either called directly or via String#new)</p>
<p><a href="http://www.ruby-doc.org/core/classes/Class.html#M000178" class="external">http://www.ruby-doc.org/core/classes/Class.html#M000178</a></p>
<p>Those are basics.</p>
<p>The issue is, that after the allocation, the <em>redefined</em> initialized should be called.</p>
<ul>
<li>
</ul>
<p>There is a public topic available, with some elaborations:</p>
<p>CORE - Literal Instantiation breaks Object Model<br>
<a href="http://groups.google.com/group/comp.lang.ruby/browse_frm/thread/fd00b89dc6d3a7fa#" class="external">http://groups.google.com/group/comp.lang.ruby/browse_frm/thread/fd00b89dc6d3a7fa#</a><br>
<a href="http://www.ruby-forum.com/topic/1893190#new" class="external">http://www.ruby-forum.com/topic/1893190#new</a></p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=180292011-06-17T07:40:48Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Rejected</i></li></ul><p>Your request has been too vague for me. Your definition of terms such as "object model" seems different from others. Probably the code will tell what you want. I will reopen this issue when a patch is posted</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=180632011-06-18T01:12:50Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>deleted by myself, duplicate post</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=180642011-06-18T01:12:51Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>Your request has been too vague for me.<br>
Your definition of terms such as "object model" seems different from others.</p>
</blockquote>
<p>I don't think so:</p>
<p>"Object Model" as in</p>
<ul>
<li>Design and implementation of a programming language's OO behaviour (classes, object, inheritance, mixin, methods, attributes, per-instance-behaviour etc.).</li>
</ul>
<p>Special part of this language's (ruby) "Object Model" is</p>
<ul>
<li>Primitive data types (integer, string, ...) are objects, and have related classes (Integer, String)</li>
<li>Classes (including those of the primitive data types) can be redefined at runtime.</li>
</ul>
<p>This is a flexible ability, but it has (in the current implementation) a limitation (essentially a bug):</p>
<ul>
<li>Limitation: a redefined initialize method is <em>not</em> called during "literal instantiation"</li>
</ul>
<blockquote>
<p>Probably the code will tell what you want.</p>
</blockquote>
<p>Mr. Matsumoto.</p>
<p>Will you honestly insist that you have not understood (after the public thread, and the compact irb demonstration) that "what I want" is:</p>
<ul>
<li>The <em>redefined</em> initialize method <em>must</em> be called during literal instantiation (when instantiating objects from literals)?</li>
</ul>
<blockquote>
<p>I will reopen this issue when a patch is posted</p>
</blockquote>
<p>This means that this issue is on "Standby" or "Feedback" and not "Rejected".</p>
<p>I think you abuse your position here, because you take the freedom to process this issue based on your personal feelings or bias, instead of the existent facts.</p>
<p>You should respect my time more (I've already invested more that a week with this issue on a OO user-level, and I need some confirmations prior to continuing on C-core-level.</p>
<p>I have to use the official ruby interpreter, thus it makes no sense for me to invest time for a patch which has no chance to be applied.</p>
<p>(Btw: This modification/patch would be the foundation to further unify the behaviour of objects within the language, especially those which are speed-critical.)</p>
<p>Possibly we can agree on this:</p>
<ul>
<li>You confirm that the issue is a limitation in the current implementation, concrete:
<ul>
<li>Limitation: a redefined initialize method is <em>not</em> called during "literal instantiation"</li>
</ul>
</li>
<li>You confirm that you will consider to apply a patch, under the condition that the patch
<ul>
<li>does not introduces a performance loss (or at least only a minimal one, e.g. < 1%)</li>
<li>does not break existent behaviour (compatibility)</li>
</ul>
</li>
<li>You place the issue back on an "Standby" / "Halted" / "Feedback" state (other than "Rejected")</li>
</ul>
<p>And then I can go on to work on a solution/patch.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=181052011-06-20T23:23:07Zaprescott (Adam Prescott)
<ul></ul><p>On Fri, Jun 17, 2011 at 5:12 PM, Lazaridis Ilias <a href="mailto:ilias@lazaridis.com" class="email">ilias@lazaridis.com</a> wrote:</p>
<blockquote>
<p>"Object Model" as in</p>
<p> * Design and implementation of a programming language's OO behaviour (classes, object, inheritance, mixin, methods, attributes, per-instance-behaviour etc.).</p>
<p>Special part of this language's (ruby) "Object Model" is</p>
<p> * Primitive data types (integer, string, ...) are objects, and have related classes (Integer, String)<br>
* Classes (including those of the primitive data types) can be redefined at runtime.</p>
<p>This is a flexible ability, but it has (in the current implementation) a limitation (essentially a bug):</p>
<p> * Limitation: a redefined initialize method is <em>not</em> called during "literal instantiation"</p>
</blockquote>
<p>Other than some abstract violation of a model, what problem is this<br>
causing? Do you have actual code in a practical situation for which<br>
this "limitation" is an obstacle? What would this solve, and what<br>
would be its direct, realisable benefit?</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=182212011-06-25T20:10:50Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>Your request has been too vague for me. Your definition of terms such as "object model" seems different from others. Probably the code will tell what you want. I will reopen this issue when a patch is posted</p>
</blockquote>
<p>Patch follows within the next day. I've worked against 1.9.2p180 (the version I've in use), hope this is ok.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=182352011-06-26T11:01:02Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul><li><strong>File</strong> <a href="/attachments/1824">String_call_initialize.diff</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1824/String_call_initialize.diff">String_call_initialize.diff</a> added</li></ul><p>Deleted by myself, duplicate post.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=182362011-06-26T11:01:03Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul><li><strong>File</strong> <a href="/attachments/1825">String_call_initialize.diff</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1825/String_call_initialize.diff">String_call_initialize.diff</a> added</li></ul><p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>Your request has been too vague for me. Your definition of terms such as "object model" seems different from others. Probably the code will tell what you want. I will reopen this issue when a patch is posted</p>
</blockquote>
<p>Find attached a draft version of the modification (against branches/ruby_1_9_2) for review. The code should be self-explaining. I've tested on windows 7 with a small test-program (functionality) and with "nmake test" (compatibility when unused).</p>
<p>As you can see, the speed overhead (default, String.call_initialize = false) is near zero (one "if" call against "int").</p>
<p>If a user wants to have his alternate "initialize" method called, he just sets "String.call_initialize = true". The initialize method is called, passing the allocated and semi-initialized string object as a parameter. The user can now process the object as needed, thus it becomes full-initialized and identical to string objects instantiated by String#new().</p>
<p>I can invest some time refined the patch further, if needed. Please just let me know your requirements.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=182372011-06-26T11:39:25Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Rejected</i> to <i>Assigned</i></li><li><strong>Assignee</strong> set to <i>matz (Yukihiro Matsumoto)</i></li></ul><p>OK, Ilias did his homework. It's your move matz. Though I don't like the call_initialize= thing (thread unsafe), the idea of calling initialize at string creation is clearly explained in the patch. I think it's worth considering.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=182382011-06-26T12:43:09Zwishdev (John Higgins)wishdev@gmail.com
<ul><li><strong>File</strong> <a href="/attachments/1826">strings.rb</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1826/strings.rb">strings.rb</a> added</li></ul><p>The patch doesn't work....</p>
<p>The 'strings.rb' file I believe is about as simple as we can get. The 'empty_file' attempted to be required in the file is just that - a completely empty file with nothing in it at all.</p>
<p>ruby strings.rb yields</p>
<p>true<br>
strings.rb:10:in <code>require_relative': method </code>initialize' called on hidden T_STRING object (0x00000000849f18 flags=0x4c005 klass=0x0) (NotImplementedError)<br>
from strings.rb:10:in `'</p>
<p>require fails - load works but require is a no go.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=182392011-06-26T12:56:15Zwishdev (John Higgins)wishdev@gmail.com
<ul></ul><p>Actually I stand slightly corrected - require/load seems to work on the empty file - but require_relative does not.</p>
<p>I apologize for the slightly misleading report.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=183732011-06-26T16:54:38Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul><li><strong>File</strong> <a href="/attachments/1827">StringInit.rb</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1827/StringInit.rb">StringInit.rb</a> added</li></ul><p>John Higgins wrote:</p>
<blockquote>
<p>The patch doesn't work....</p>
</blockquote>
<p>The basic functionality works (see a simple test StringInit.rb), although there's work to do for a final version.</p>
<p>Remember that this is a draft version, mainly to demonstrate how it can work and to collect some requirements for a final implementation.</p>
<blockquote>
<p>The 'strings.rb' file I believe is about as simple as we can get. The 'empty_file' attempted to be required in the file is just that - a completely empty file with nothing in it at all.</p>
</blockquote>
<p>Good "catch".</p>
<p>The error occurs when "rb_str_new_frozen" is used to create the string internally. Will look into this.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=184402011-06-26T18:36:47Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Lazaridis Ilias wrote:</p>
<blockquote>
<p>John Higgins wrote:</p>
<blockquote>
<p>The patch doesn't work....</p>
</blockquote>
</blockquote>
<p>Seems you were right, essentially it does not work (only in my small scope test)</p>
<blockquote>
<p>The error occurs when "rb_str_new_frozen" is used to create the string internally. Will look into this.</p>
</blockquote>
<p>I've to call "initialize" from "rb_str_new" instead from "str_new".</p>
<p>Will post a corrected patch tomorrow, after testing against the whole test-suite.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=184972011-06-26T20:06:15Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul><li><strong>File</strong> <a href="/attachments/1829">String_call_initialize_v2.diff</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1829/String_call_initialize_v2.diff">String_call_initialize_v2.diff</a> added</li><li><strong>File</strong> <a href="/attachments/1830">bootstraptest_runner_addition.diff</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1830/bootstraptest_runner_addition.diff">bootstraptest_runner_addition.diff</a> added</li></ul><p>Lazaridis Ilias wrote:<br>
[...]</p>
<blockquote>
<p>I've to call "initialize" from "rb_str_new" instead from "str_new".</p>
<p>Will post a corrected patch tomorrow, after testing against the whole test-suite.</p>
</blockquote>
<p>The v2 patch works on my site, tested with "nmake test" whilst adding a String running_counter (see file "bootstraptest_runner_addition") to the tests.</p>
<p>All tests pass and the counter behaves as expected.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=185622011-06-27T18:47:20Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>I'd like to test the modification against the sources which are to become 1.9.3 (and which contain the IBM737 transcoder). Would this be "trunk"?</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=185632011-06-27T19:11:59Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul></ul><p>Not sure about IBM737 but yes, 1.9.3 branch will be created from trunk.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=186292011-06-28T20:49:04Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Shyouhei Urabe wrote:</p>
<blockquote>
<p>Not sure about IBM737 but yes, 1.9.3 branch will be created from trunk.</p>
</blockquote>
<p>Ok, I'm working now against trunk. "nmake test" with the applied "bootstraptest_runner_addition.diff" passes "nmake test". Can I do more, or am I at the point where I have to wait?</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=186502011-06-29T09:31:25Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul></ul><p>Please wait matz. Maybe you can nudge him.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=186962011-06-30T21:00:18Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Shyouhei Urabe wrote:</p>
<blockquote>
<p>Please wait matz. Maybe you can nudge him.</p>
</blockquote>
<p>Would like to avoid to "nudge" him, he seems to be busy with other tasks. I try today the test-all and test-specs, and then I can try the final implementation (for which I'll need most possibly some help).</p>
<ul>
<li>call_initialize is set to true, whenever the redefinition of initialize is detected.</li>
<li>call_initialize is set to false, whenever the original initialize becomes active again.</li>
</ul>
<p>This would be the ideal implementation, fully transparent to the user. If the definition of methods happens with <em>one</em> low-level function/method, then it should be simple.</p>
<p>Maybe you can help me with some information:</p>
<p>a) who is the maintainer of string.c ?<br>
b) is there a standard-hook to include custom test-code before the execution of the test-all / test-specs suite?</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=187092011-07-01T02:13:22Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Rejected</i></li></ul><p>Introducing a new global status is a very bad idea. It doesn't work<br>
well with threads. Besides that, it makes program behavior more<br>
complex and less understandable. It's not acceptable for new<br>
addition.</p>
<pre><code> matz.
</code></pre> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=187342011-07-01T14:12:22Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>Introducing a new global status is a very bad idea. It doesn't work well with threads.</p>
</blockquote>
<p>All threads share the same (global) instance of the String class object, thus the flag "call_initialize" is naturally global.</p>
<blockquote>
<p>Besides that, it makes program behavior more complex and less understandable.</p>
</blockquote>
<p>I've described the final implementation, which makes "call_initialize" an internal implementation detail, completely hidden from the user.</p>
<p>Currently, I wanted a confirmation that the patch works <em>technically</em>, thus I can go on to the next step (= incremental design/implementation).</p>
<blockquote>
<p>It's not acceptable for new addition.</p>
</blockquote>
<p>Why do you place the issue again on "reject", instead of awaiting the final implementation?</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=187382011-07-01T22:59:43Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>Lazaridis Ilias wrote:</p>
<blockquote>
<p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>Introducing a new global status is a very bad idea. It doesn't work well with threads.</p>
</blockquote>
<p>All threads share the same (global) instance of the String class object, thus the flag "call_initialize" is naturally global.</p>
</blockquote>
<p>So that means the whole idea of having call_initialize is a very bad idea, from my point of view.</p>
<blockquote>
<p>Why do you place the issue again on "reject", instead of awaiting the final implementation?</p>
</blockquote>
<p>I ask you to show us a concrete description of you request. You have shown the basic outline of your idea by a patch, which appeared to be a bad idea. As a natural consequence, I rejected. Show me the outline of your so-called "final implementation", by working code, not by words in vain. Then I will "resurrect" the issue again, I promise.</p>
<p>matz.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=187542011-07-02T18:22:20Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>Lazaridis Ilias wrote:</p>
<blockquote>
<p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>Introducing a new global status is a very bad idea. It doesn't work well with threads.</p>
</blockquote>
<p>All threads share the same (global) instance of the String class object, thus the flag "call_initialize" is naturally global.</p>
</blockquote>
<p>So that means the whole idea of having call_initialize is a very bad idea, from my point of view.</p>
</blockquote>
<p>This means that it's technically/functionally not a problem (although I don't like the current implementation of flag, too).</p>
<blockquote>
<blockquote>
<p>Why do you place the issue again on "reject", instead of awaiting the final implementation?</p>
</blockquote>
<p>I ask you to show us a concrete description of you request. You have shown the basic outline of your idea by a patch, which appeared to be a bad idea. As a natural consequence, I rejected.</p>
</blockquote>
<p>I start to understand how you use "rejected". In order to avoid to discuss the issue-tracking-process here, I've opened an new issue:</p>
<p><a href="http://redmine.ruby-lang.org/issues/4963" class="external">http://redmine.ruby-lang.org/issues/4963</a></p>
<blockquote>
<p>Show me the outline of your so-called "final implementation", by working code, not by words in vain. Then I will "resurrect" the issue again, I promise.</p>
</blockquote>
<p>I still need to verify that this draft implementation does not break existent behaviour. If assumed that passing all "make test" is not enough, and indeed "make test-all" uncovered some problems.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=187742011-07-03T01:35:20Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul><li><strong>File</strong> <a href="/attachments/1846">test_runner_String_initialize.diff</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1846/test_runner_String_initialize.diff">test_runner_String_initialize.diff</a> added</li></ul><p>Lazaridis Ilias wrote:<br>
[...]</p>
<blockquote>
<p>I still need to verify that this draft implementation does not break existent behaviour. If assumed that passing all "make test" is not enough, and indeed "make test-all" uncovered some problems.</p>
</blockquote>
<p>Find attached the modification for test/runner.rb in order to run "make test-all".</p>
<p>Five tests failed, all with the same message: "Insecure: can't set class variable."</p>
<p>test_safe_04(TestERBCore):<br>
test_safe_04(TestERBCoreWOStrScan):<br>
test_safe4(TestException) [P:/sand/rubyi2/sandbox/ruby193/test/ruby/test_exception.rb:243]:<br>
test_exec_recursive(TestObject):<br>
test_taint(TestRegexp) [P:/sand/rubyi2/sandbox/ruby193/test/ruby/test_regexp.rb:495]:</p>
<p>Seems to have to do with the "tainted" mechanism, not sure if the access to the class-variable should be disallowed (the class object String is <em>not</em> tainted, only it's instances). But that's not the issue, as it's a detail of the test code.</p>
<ul>
<li>
</ul>
<p>I'll move tomorrow on, implementing the final (production) version. Can someone inform me please about this:</p>
<ul>
<li>is there a standard mechanism to detect "singleton-method created/deleted", which works on the C-level?</li>
</ul>
<p>[please note that the UI here does not allow me to reopen an issue by myself].</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=188062011-07-04T21:02:15Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul><li><strong>File</strong> <a href="/attachments/1851">String_call_initialize_v3.diff</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1851/String_call_initialize_v3.diff">String_call_initialize_v3.diff</a> added</li></ul><p>Find attached a patch which removes the translation-unit-visible "static int call_initialize" flag, and introduces the low-level flag "FL_USER18" of the String class object.</p>
<p>There was no documentation about those flags. "FL_USER18" seemed unused, please let me know if I should use another one.</p>
<p>Lazaridis Ilias wrote:<br>
[...]</p>
<blockquote>
<ul>
<li>is there a standard mechanism to detect "singleton-method created/deleted", which works on the C-level?</li>
</ul>
</blockquote>
<p>I've found the "(singleton_)method_added/removed/undefined group of call-backs, those should be usable to implement the last step (automated activation/deactivation of the flag).</p>
<ul>
<li>
</ul> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=188072011-07-04T21:11:02Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul><li><strong>File</strong> <a href="/attachments/1852">String_call_initialize_v3b.diff</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1852/String_call_initialize_v3b.diff">String_call_initialize_v3b.diff</a> added</li></ul><p>Please ignore patch "String_call_initialize_v3", it contains a merge-error.</p>
<p>New version: String_call_initialize_v3b</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=188122011-07-05T00:28:47Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Lazaridis Ilias wrote:<br>
[...]</p>
<blockquote>
<p>I've found the "(singleton_)method_added/removed/undefined group of call-backs, those should be usable to implement the last step (automated activation/deactivation of the flag).</p>
</blockquote>
<p>Although it's possible to automatically activate/deactivate the flag, it seems preferable to require that this is done explicitly by the user.</p>
<p>The explicit setting of "String.call_initialize = true|false" ensures that a users knows what he's doing, and that he is aware about the involved speed loss.</p>
<p>The patch "String_call_initialize_v3b.diff" is the suggested final version.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=188132011-07-05T00:44:54Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>Perhaps you don't (want to) understand my comment. Introducing new global status is not acceptable as String's new feature. Period.</p>
<p>matz.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=188222011-07-05T02:07:19Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>Perhaps you don't (want to) understand my comment.</p>
</blockquote>
<p>Perhaps you don't (want to) understand a technically perfectly valid solution?</p>
<blockquote>
<p>Introducing new global status is not acceptable as String's new feature. Period.</p>
</blockquote>
<p>DEFINITION:</p>
<p>What do you mean with "global status"?</p>
<p>Would it be still a "global status", if the flag would be set automatically and internally, without user intervention?</p>
<p>INFLUENCE:</p>
<p>Why is it not acceptable?</p>
<p>What is your rationale?</p>
<p>Can you backup this rationales with test-code?</p>
<ul>
<li>
</ul>
<p>Maybe <em>you</em> should now use <em>code</em> to express what do you mean with "global status" etc., because your attitude is <em>very</em> counter productive and <em>very</em> ungentle against a person which has invested nearly two weeks to produce this <em>technically</em> <em>valid</em> solution.</p>
<p>You wrote earlier:</p>
<p>"Show me the outline of your so-called "final implementation", by working code, not by words in vain. "</p>
<p>Now I say (using your wording):</p>
<p>Show me the outline of your so-called "global status" problem, by working test-code, not by words in vain.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=188242011-07-05T02:45:15Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>|DEFINITION:<br>
|<br>
|What do you mean with "global status"?</p>
<p>That something you implemented by the C global variable in this case.</p>
<p>|Would it be still a "global status", if the flag would be set automatically and internally, without user intervention?</p>
<p>Depends on the automatic set strategy, which you haven't told me.</p>
<p>|INFLUENCE:<br>
|<br>
|Why is it not acceptable?</p>
<p>The global status tends to make program behavior unpredictable,<br>
especially under threading environment.</p>
<pre><code> matz.
</code></pre> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=188392011-07-05T22:46:24Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>|DEFINITION:<br>
|<br>
|What do you mean with "global status"?</p>
<p>That something you implemented by the C global variable in this case.</p>
</blockquote>
<ul>
<li>I do not use a "C global variable", but a class-object variable.</li>
<li>There is no "global status", but a class-object status.</li>
</ul>
<blockquote>
<p>|Would it be still a "global status", if the flag would be set automatically and internally, without user intervention?</p>
<p>Depends on the automatic set strategy, which you haven't told me.</p>
</blockquote>
<p>I've described the outline.</p>
<p>But it would be nice if you would tell me a strategy, which would make you accept that it's not a "global status".</p>
<p>Possibly this way I can understand your interpretation "global status".</p>
<blockquote>
<p>|INFLUENCE:<br>
|<br>
|Why is it not acceptable?</p>
<p>The global status tends to make program behavior unpredictable,<br>
especially under threading environment.</p>
</blockquote>
<p>I understand that, but this is not the case here:</p>
<p>VARIABLE:</p>
<ul>
<li>I don't use <em>any</em> global variable (but an internal class-object scope variable)</li>
<li>I use the same (string-)class-object scope flags that are used <em>excessively</em> within the existent ruby source-codes.</li>
</ul>
<p>STATUS:</p>
<ul>
<li>The status is class-object-bound (exactly as the status "redefined initialize method exists" is)</li>
<li>The test-all passes (with an activated redefined String#initialize)</li>
</ul>
<p>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.</p>
<p>[And may I remind you that this issue is still on status "rejected". This is not the way issues are processed: if they exist, they are open/assigned/feedback, until rejected/closed.]</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=188402011-07-05T23:23:06Znow (Nikolai Weibull)now@disu.se
<ul></ul><p>On Tue, Jul 5, 2011 at 15:46, Lazaridis Ilias <a href="mailto:ilias@lazaridis.com" class="email">ilias@lazaridis.com</a> wrote:</p>
<blockquote>
<ul>
<li>I do not use a "C global variable", but a class-object variable.</li>
<li>There is no "global status", but a class-object status.</li>
</ul>
</blockquote>
<p>The point is that it’s still a global.</p>
<p>But that’s really beside the point. Why even have<br>
#call_initialize/#call_initialize=? Simply always invoke #initialize<br>
instead:</p>
<p>diff --git a/string.c b/string.c<br>
index 711918b..8bdf650 100644<br>
--- a/string.c<br>
+++ b/string.c<br>
@@ -409,7 +409,11 @@ str_new(VALUE klass, const char *ptr, long len)<br>
VALUE<br>
rb_str_new(const char *ptr, long len)<br>
{</p>
<ul>
<li>return str_new(rb_cString, ptr, len);</li>
</ul>
<ul>
<li>VALUE str = str_new(rb_cString, ptr, len);</li>
<li>
<li>rb_obj_call_init(str, 1, &str);</li>
<li>
<li>return str;<br>
}</li>
</ul>
<p>VALUE</p>
<p>I suspect that this modification (in whatever form it eventually ends<br>
up being) should also be done to rb_str_new_with_class().</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=188662011-07-06T17:17:59Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>|VARIABLE:<br>
|* I don't use <em>any</em> global variable (but an internal class-object scope variable)<br>
|* I use the same (string-)class-object scope flags that are used <em>excessively</em> within the existent ruby source-codes.</p>
<p>OK, you don't use the C global variable any longer. But still uses<br>
global status, that I mean a line of</p>
<p>String.call_initialize=true</p>
<p>in anywhere in the program can change the whole behavior of whole<br>
program so much. Comparing to other usage of global statuses (some of<br>
which I regret), influence of this change is too huge.</p>
<p>|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.</p>
<p>Did you measured the performance?</p>
<pre><code> matz.
</code></pre> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=188792011-07-07T05:26:15Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>|VARIABLE:<br>
|* I don't use <em>any</em> global variable (but an internal class-object scope variable)<br>
|* I use the same (string-)class-object scope flags that are used <em>excessively</em> within the existent ruby source-codes.</p>
<p>OK, you don't use the C global variable any longer. But still uses<br>
global status, that I mean a line of</p>
<p>String.call_initialize=true</p>
<p>in anywhere in the program can change the whole behavior of whole<br>
program so much.</p>
</blockquote>
<p>This is really a (class)local status, see this issue subjecting terminology:</p>
<p><a href="http://redmine.ruby-lang.org/issues/4984" class="external">http://redmine.ruby-lang.org/issues/4984</a></p>
<blockquote>
<p>Comparing to other usage of global statuses (some of<br>
which I regret), influence of this change is too huge.</p>
</blockquote>
<p>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.</p>
<p>See it otherwise:</p>
<p>You had good reasons to bypass the method-lookup by using the internal initialize method directly (resulted in higher execution speed).</p>
<p>Essentially you've introduced an invisible (class)local status, something like "String.speedy_initialize=true".</p>
<p>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.</p>
<blockquote>
<p>|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.</p>
<p>Did you measured the performance?</p>
</blockquote>
<p>I could not measure any speed difference with the call inactive (call_initialize=false), as it's minimal. Thus unused there's no difference.</p>
<p>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.</p>
<p>In any way: the user who needs this feature should understand the speed issues.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=188842011-07-07T07:51:28Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>|This is really a (class)local status, see this issue subjecting terminology:<br>
|<br>
|<a href="http://redmine.ruby-lang.org/issues/4984" class="external">http://redmine.ruby-lang.org/issues/4984</a></p>
<p>I am sorry but I don't understand what you mean by issue <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: [TERMINOLOGY] Provide Document for Terminology (e.g. "Global Status") (Rejected)" href="https://bugs.ruby-lang.org/issues/4984">#4984</a>. Both<br>
global status and local status has String.call_initialize in examples.</p>
<p>Class objects can be accessed from everywhere. A modifiable attribute<br>
of a globally accessible object is global status, in my terminology.</p>
<p>|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.</p>
<p>I understand you have different criteria from me. At least, I hate<br>
that "worst case".</p>
<p>|> Did you measure the performance?<br>
|<br>
|I could not measure any speed difference with the call inactive (call_initialize=false), as it's minimal. Thus unused there's no difference.<br>
|<br>
|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.<br>
|<br>
|In any way: the user who needs this feature should understand the speed issues.</p>
<p>Thus adding one thing to worry to the language performance? Once the<br>
feature added, that could be "abused" beyond your expectation. What<br>
if that feature is used deep inside of the third party library?<br>
People would blame not only the author of the library, but the<br>
language and me for decreasing performance. I am not ready nor<br>
enthusiastic to accept that kind of complains for this particular<br>
feature.</p>
<p>But Ilias, you are safe. Since no one cares who proposed the feature.<br>
That is the very reason I recommend you to fork the language off from<br>
Ruby. Don't bother us.</p>
<p>By the way, I have noticed that your patch invokes initialize with the<br>
receiver itself, which is not yet initialized, as an argument. That<br>
makes me feel weird. That might satisfy your particular requirement,<br>
but I don't consider it consistent as you claim.</p>
<pre><code> matz.
</code></pre> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=189742011-07-09T18:35:37Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>|This is really a (class)local status, see this issue subjecting terminology:<br>
|<br>
|<a href="http://redmine.ruby-lang.org/issues/4984" class="external">http://redmine.ruby-lang.org/issues/4984</a><br>
[...]</p>
</blockquote>
<p>Commented there.</p>
<blockquote>
<p>|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.</p>
<p>I understand you have different criteria from me. At least, I hate<br>
that "worst case".</p>
</blockquote>
<p>Different criteria, possibly.</p>
<ul>
<li>I "hate" that the current 1.9.2 does not call a redefined initialize at all.</li>
<li>It would be ok if 1.9.x would not call a redefined initialize, because I forgot to set the flag.</li>
</ul>
<p>Anyway, this is an implementation detail. If you really hate this, the flag could become invisible to the user (automated setting).</p>
<blockquote>
<p>|> Did you measure the performance?<br>
|<br>
|I could not measure any speed difference with the call inactive (call_initialize=false), as it's minimal. Thus unused there's no difference.<br>
|<br>
|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.<br>
|<br>
|In any way: the user who needs this feature should understand the speed issues.</p>
<p>Thus adding one thing to worry to the language performance? Once the<br>
feature added, that could be "abused" beyond your expectation. What<br>
if that feature is used deep inside of the third party library?<br>
People would blame not only the author of the library, but the<br>
language and me for decreasing performance. I am not ready nor<br>
enthusiastic to accept that kind of complains for this particular<br>
feature.<br>
But Ilias, you are safe. Since no one cares who proposed the feature.</p>
</blockquote>
<p>Based on your reasoning, you should remove the "RUBY_EVENT_*" mechanism, as it can be "used deeply inside a third party library", decreasing the <em>overall</em> speed of the interpreter.</p>
<p>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?</p>
<p>Anyway, I understand your reasoning, and I would possibly agree, if this issue would be a "feature request".</p>
<p>It's not. This issue is about to make the interpreter feature-complete, to remove a limitation of the implementation.</p>
<p>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).</p>
<p>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.</p>
<blockquote>
<p>That is the very reason I recommend you to fork the language off from<br>
Ruby. Don't bother us.</p>
</blockquote>
<p>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.</p>
<p>But here I really just want to remove a small limitation of the current implementation.</p>
<blockquote>
<p>By the way, I have noticed that your patch invokes initialize with the<br>
receiver itself, which is not yet initialized, as an argument.</p>
</blockquote>
<p>Please look again at the code. It is initialized.</p>
<p>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.</p>
<p>An implementation detail, which can be changed (although it seems not necessary).</p>
<blockquote>
<p>That<br>
makes me feel weird. That might satisfy your particular requirement,<br>
but I don't consider it consistent as you claim.</p>
</blockquote>
<p>It's more consistent than the existent implementation, and it passes the test-all.</p>
<p>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, ...).</p>
<p>In other words: the current implementation is not consistent. Adding one missing feature (this issue) cannot make it consistent.</p>
<p>.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=190252011-07-10T15:35:19Znaruse (Yui NARUSE)naruse@airemix.jp
<ul><li><strong>Tracker</strong> changed from <i>Bug</i> to <i>Feature</i></li><li><strong>Status</strong> changed from <i>Rejected</i> to <i>Assigned</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>3</i></li></ul><p>Matz, this is long-term issue.<br>
Can you handle other issues before you handle this?</p>
<p>See <a href="http://redmine.ruby-lang.org/projects/ruby-19/issues?query_id=72" class="external">http://redmine.ruby-lang.org/projects/ruby-19/issues?query_id=72</a></p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=191182011-07-13T06:10:40Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>=begin<br>
related issue <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: method_added" is called in addition to "method_undefined (Closed)" href="https://bugs.ruby-lang.org/issues/5015">#5015</a></p>
<p>=end</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=191192011-07-13T08:18:20Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul><li><strong>File</strong> <a href="/attachments/1884">String_call_initialize_v4.diff</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1884/String_call_initialize_v4.diff">String_call_initialize_v4.diff</a> added</li></ul><p>Attached an updated patch, where the flag becomes an internal implementation detail, not accessible from outside.</p>
<p>test-all passes, having this code within test/runner.rb active:</p>
<p>class String<br>
@@running_counter = 0<br>
alias :orig_initialize :initialize<br>
def initialize(*args)<br>
orig_initialize(*args)<br>
@@running_counter += 1<br>
end<br>
def self.running_counter<br>
@@running_counter<br>
end<br>
end</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=191472011-07-14T02:40:07Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Although the latest version (v4) works fine, I dislike to use the callbacks to set/clear the flag.</p>
<p>I have "fuzzily" the perfect implementation in mind, but it will take a few days until it becomes clear. Until then, I would be "glad" if someone detects a problem with the existent solution.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=191482011-07-14T03:37:55Zwishdev (John Higgins)wishdev@gmail.com
<ul></ul><p>Lazaridis Ilias wrote:</p>
<blockquote>
<p>Although the latest version (v4) works fine, I dislike to use the callbacks to set/clear the flag.</p>
<p>I have "fuzzily" the perfect implementation in mind, but it will take a few days until it becomes clear. Until then, I would be "glad" if someone detects a problem with the existent solution.</p>
</blockquote>
<p>You are hijacking the callbacks - if anyone implemented any of the callbacks your implementation fails because your callbacks won't fire anymore</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=191492011-07-14T03:53:12Zjudofyr (Magnus Holm)judofyr@gmail.com
<ul></ul><p>YARV already has flags to see if methods are redefined (used for fast<br>
numeric operations). Maybe you could use them? See<br>
vm_init_redefined_flag(void) in vm.c.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=192082011-07-17T09:10:29Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>John Higgins wrote:<br>
[...]</p>
<blockquote>
<p>You are hijacking the callbacks - if anyone implemented any of the callbacks your implementation fails because your callbacks won't fire anymore</p>
</blockquote>
<p>You're right, that's one reason I dislike to use the callbacks.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=192092011-07-17T09:17:43Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Magnus Holm wrote:</p>
<blockquote>
<p>YARV already has flags to see if methods are redefined (used for fast<br>
numeric operations). Maybe you could use them? See<br>
vm_init_redefined_flag(void) in vm.c.</p>
</blockquote>
<p>This sounds plausible. But due to the many delays, I've not much energy/focusation left for this issue, and thus I avoid to change the taken path. But I'll take for sure a look later.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=192202011-07-17T11:56:35Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul><li><strong>File</strong> <a href="/attachments/1897">String_call_initialize_v5.diff</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1897/String_call_initialize_v5.diff">String_call_initialize_v5.diff</a> added</li></ul><p>Not "perfect", but should be stable and adoptable to other classes.</p>
<p>Needs possibly some renaming, and finally a review of Mr. Holms tip subjecting YARV/vm_init_redefined_flag(void). But once more, I need to take distance for some days.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=192212011-07-17T12:01:20Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul><li><strong>File</strong> <a href="/attachments/1898">String_call_initialize_v5b.diff</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1898/String_call_initialize_v5b.diff">String_call_initialize_v5b.diff</a> added</li></ul> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=192742011-07-18T03:06:41Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Lazaridis Ilias wrote:</p>
<blockquote>
<p>Not "perfect", but should be stable and adoptable to other classes.</p>
<p>Needs possibly some renaming,</p>
</blockquote>
<p>rb_set_call_flags -> rb_set_redefined_flags<br>
rb_obj_call_init_fast -> rb_call_init_if_redefined</p>
<p>This name change "clarifies" that the flag belongs not to the class-object, but to the method-object (method-struct). So it's going "naturally" one step closer to the suggestion below:</p>
<blockquote>
<p>and finally a review of Mr. Holms tip subjecting YARV/vm_init_redefined_flag(void). But once more, I need to take distance for some days.</p>
</blockquote>
<p>Now, distance again!</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=192752011-07-18T03:19:51Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>=begin<br>
Note: I've used tab-4 in the latest patch (v5b) by accident. See the issue <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: C Source Code formatting (Rejected)" href="https://bugs.ruby-lang.org/issues/5034">#5034</a><br>
=end</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=194392011-07-21T14:24:29Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul><li><strong>File</strong> <a href="/attachments/1907">String_call_initialize_v6.diff</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1907/String_call_initialize_v6.diff">String_call_initialize_v6.diff</a> added</li></ul><p>This one should do the work fine.</p>
<p>Further optimization / normalization (and thus increase of the overall method-handling consistency) depends on some refactoring (and slight redesign) of existent units, especially vm_method.c. I'll possibly file two or three issues to give an overview of the necessary tasks.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=196082011-07-24T14:13:44Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>=begin<br>
Related issue: <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Refactor and Document vm_method.c / method.h (Closed)" href="https://bugs.ruby-lang.org/issues/5088">#5088</a> (Refactor and Document vm_method.c / method.h)<br>
=end</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=196132011-07-24T22:23:03Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Rejected</i></li></ul><p>Calling a hook from rb_str_new() is insane.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=196202011-07-24T23:55:29Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Nobuyoshi Nakada wrote:</p>
<blockquote>
<p>Calling a hook from rb_str_new() is insane.</p>
</blockquote>
<p>Mr. Nakada, when the influence of the alcohol goes away, look once more at the code.</p>
<p>Possibly you'll see that I don't call any hooks. It's the existent code, not my modification.</p>
<p>In any way: it's no reason to once more place the issue on "rejected", this starts to become very annoying.</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=199332011-08-02T02:06:24Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>Lazaridis Ilias wrote:</p>
<blockquote>
<p>Nobuyoshi Nakada wrote:</p>
<blockquote>
<p>Calling a hook from rb_str_new() is insane.</p>
</blockquote>
<p>Mr. Nakada, when the influence of the alcohol goes away, look once more at the code.</p>
<p>Possibly you'll see that I don't call any hooks. It's the existent code, not my modification.</p>
<p>In any way: it's no reason to once more place the issue on "rejected", this starts to become very annoying.</p>
</blockquote>
<p>Can please someone with access reopen the issue?</p> Ruby master - Feature #4893: Literal Instantiation breaks Object Modelhttps://bugs.ruby-lang.org/issues/4893?journal_id=209242011-09-21T16:11:37Zlazaridis.com (Lazaridis Ilias)ilias@lazaridis.com
<ul></ul><p>=begin</p>
<p>related issue: <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Please Reopen Issue #4893 (Rejected)" href="https://bugs.ruby-lang.org/issues/5346">#5346</a></p>
<p>=end</p>