On 10 , 01:30, Yukihiro M. email@example.com wrote:
|This is essentially a defect, as the consistency of the Object Model
You don’t have to teach me about Ruby’s object model.
I’m writing here in comp.lang.ruby, addressing the public, not you
But: of course I can teach you something about the object model,
especially because you have designed it. Because you are - as the
language designer and implementer - far to deep in the internals, in
order to view the model (and the language in general) strictly from a
users view. You miss some basics - that’s natural.
for literals are already created in the compile time, which is far
before you redefine the initialize method.
Basics: Interpreted language, OO
From my (OO user) point of view, there is no compile-time.
And my OO-level code supersedes the core-level code. Because the core-
level code is simply there to serve my OO-level code (which has more
The individual string
objects from literals are just copy of the already allocated and
you say: “Individual string objects”
Those are not String objects, as their related initialize method was
not called (remember: my user OO-code supersedes naturally the core-
If those would be instances of a class like StringLiterals, it would
The whole purpose of the initialize method is to
initialize newly created objects, as the name suggests.
The “initialize” method is the constructor. By definition, an object
must call the constructor, to become an instance of the class.
I don’t feel
any need to call the (redefined) initialize method for string
literals, that already initialized at the compile time.
This is not about “feelings” and “needs”, but about strictness.
If I use a valid language-construct to override the constructor, then
the language must call the modified constructor in order to be
compliant to the OO-model/language. If the language designer “feels”
otherwise… then it has to control those feelings.
Or he must clearly state, that those are not objects of class
Even if you
can use it to track object creation, it’s only a side-effect. I am
not going to change the language (or its object model) to fit your
Here I’m asking here the public (including you of course), if there’s
a workaround available / possible.
Neither here, nor on the issue-track I’ve asked you to “change the
language (or its object model)”, but to deal with an inconsistency -
at least to acknowledge the known issue.
Knowing that there is an issue, enables interested people to
collaborate in order to solve it.
In general, if you want a perfect language that satisfies every random
ideas popping in your mind, you’d better design your own language,
rather than trying to hijacking existing one.
I am sorry to hear you talking like this, although I believe it was
simply a bad moment.
The few issues that I’ve filed are for sure not “random popping
ideas”. Mostly, they are either user needs or usage barriers.
“hijacking” implies “stealing” “taking away”.
As for “my language”: I’m not interested to design my own language (at
least not now). Designing a processor would fit my interests more -
but I’ve no time for such hobbies (as I could most possibly never beat
the “big players”).
I simply try to use this language, to report issues which can evolve
the language positively, whilst increasing it’s consistency and
flexibility. You don’t even have to understand every use-case. There
are users which supersede e.g. your ability in framework-design. Those
users need some constructs (implementable only in C-core-level), and
those constructs enhance the language in general (none is forced to
use them or course). The next user will find those constructs build-in
and choose the language possibly exactly for this tiny construct.
I am talking here about 5 to 10 issues (estimated).
|The questions are:
|b) Is there any way to track (intercept) the instantiation of objects
|(especially those instantiated from literals)
| 1) without a C-level extension
| 2) with a C-level extension
If you don’t care about performance, you can investigate
ObjectSpace#each_object. Note that JRuby turns off the method by
default for performance reason.
ObjectSpace#each_object is not the solution (by design).
A possible solution would be this one:
If you care about performance, I am
afraid that you have to modify the interpreter itself.
Modifying the interpreter is not an option for me - at least not if
the modification is not to be included in core.
And here comes the most important issue:
If a person with over two decades of experience in hard- system- and
firmware-design shows interest to contribute on C-core-level, then you
should encourage this instead of suggesting that he is trying to
“hijack” the language.
You should say “ok, Mr. X can help you to find the relevant sources
and constructs”, not “go find another language or write your own”.
Finally I’d like to say:
The issue “Literal Instantiation breaks Object Model” is crystal-
clear. It should not take anyone more than 15min. to accept it as a
“known issue, trade-off for execution speed”. That’s really nothing
This is how evolution works: accept the issue (weakness, defect, trade-
off, …), collect relevant information, make it available for
interested people, wait till someone claims the issue and hopefully
comes up with a solution.
“Ruby 2.0 - Everything First Class Objects”
Or can it become ruby 1.9.5?