From: Ilias Lazaridis <ilias@...>
Date: 2011-06-25T16:11:35+09:00
Subject: Re: REWORK - Task: Unify behaviour of by-literal-instantiated Objects

On 21 Ιούν, 04:14, Ilias Lazaridis <il...@lazaridis.com> wrote:
> (Note: This task is part of the RUBY REWORK, which has (among other
> goals) the goal to remove inconsistencies and limitations in the
> Object Model and in the language. The time frame for the overall
> rework is 3 months.)
>
> INTRODUCTION
>
> In ruby, the primitive data types are objects (instances of their
> related classes, like Integer or String)
>
> Ruby's object model allows modifications of a class at runtime, even
> if it is the class of a  primitive data-type.
>
> This is official functionality of the object model, which is
> attractive, and provides flexibility - e.g. for framework design.
>
> As a very simple example, a "running_counter" for the String class.
>
> # altering the behaviour of the *original* String class, without sub-
> classing
> # this alteration is valid program wide
> class String
>   @@running_counter = 0
>
>   def initialize(val)
>     @@running_counter += 1
>     self.replace(val)
>   end
>
>   def running_counter
>     @@running_counter
>   end
> end
>
> #now the strings contain a running_counter, convenient accessible via
> an instance method
>
> oo_string = String.new("The String 1")
> p oo_string.running_counter #=> 1
>
> oo_string = String.new("The String 2")
> p oo_string.running_counter #=> 2
>
> LIMITATION
>
> The current implementation of ruby 1.9.2 has the following limitation:
>
> String objects instantiated from literals behave different.
>
> li_string = "The String 3"
> p li_string.running_counter #=> 2, was not incremented
>
> li_string = "The String 4"
> p li_string.running_counter #=> 2, was not incremented
>
> Although they should have the same behaviour, as they are instances of
> class String, they have a slight different behavior.
>
> -
>
> The task is, to modify the ruby interpreter, thus objects instantiated
> from literals behave like normally created objects, thus the above
> code works as expected (the redefined initialize method is called).
>
> Internally:
>
> * the C-core calls the redefined "initialize" method of an object, if
> it's available
>
> Implementation Requirements:
>
> * Minimal influence on execution speed (< 1% if feature is unused,
> interpreter dependent if feature is used )

met

> * Reusable functionality (future unification of object model, e.g. to
> make speed-critical items first-class-objects)

met

> Needed Resources:
>
> * time  : 1 week of time

met

> * budget: 500,- Euro

met (task fulfilled with 0,- Euro)

> Needed Assistance (via emails):
>
> ideally:
> * Around 1 hour from a person with toolchain experiences (VC++ express
> or mingw)
> * Around 1 hour from a person which is familiar with the ruby C source
> codes
> * Around 1 hour from a person which is familiar with the ruby cross-
> platform testing

not needed finally

> Work Plan:
>
> * 1 day : setup of tool-chain (compiler, debugger, IDE)
> * 1 day : looking around in source code
> * 1 day : implementation of 1st solution
> * 1 day : implementation of 2nd solution
> * 1 day : choose solution, refactoring, tests and documentation
> * 1 day : spare day
>
> -
>
> If you would like to see this task fulfilled, and want to provide the
> mentioned assistance or part of the budget (or a means to collect the
> budget within a public system), please contact me with private email.

exactly 0 (zero) persons have contacted me.

> -
> -
> -
>
> Related Issues:
>
> Literal Instantiation breaks Object Model
> http://redmine.ruby-lang.org/issues/4893

You'll find further information in the above issue.

> Provide Class#cb_object_instantiated_from_literal(object)
> http://redmine.ruby-lang.org/issues/4845
>
> Unify Variable Expansion within Strings
> http://redmine.ruby-lang.org/issues/487

.

--
http://lazaridis.com