From: Ilias Lazaridis Date: 2011-06-11T03:00:26+09:00 Subject: Re: CORE - Literal Instantiation breaks Object Model On 10 Éïýí, 01:30, Yukihiro Matsumoto wrote: > Hi, > > In message "Re: CORE - Literal Instantiation breaks Object Model" >     on Fri, 10 Jun 2011 03:40:27 +0900, Ilias Lazaridis writes: > > |The behaviour of the class String has been altered, whilst using the > |standard mechanisms of the Object Model. > | > |To my huge surprise, although the li_string has been instantiated as > |an object of class String, the new initialize method was not called. > | > |This is essentially a defect, as the consistency of the Object Model > |breaks. > > 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 personally. 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. > String objects > 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 importance). > The individual string > objects from literals are just copy of the already allocated and > initialized objects.   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- level code) If those would be instances of a class like StringLiterals, it would be different. > 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 String. > 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 > purpose better. 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: Provide Class#cb_object_instantiated_from_literal(object) http://redmine.ruby-lang.org/issues/4845 > 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 special. 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? . -- http://lazaridis.com