Re: CORE - Literal Instantiation breaks Object Model

On 10 =C9=EF=FD=ED, 01:30, Yukihiro Matsumoto <[e-mail]> wrote:
> Hi,
>
> In message "Re: CORE - Literal Instantiation breaks Object Model"
> =A0 =A0 on Fri, 10 Jun 2011 03:40:27 +0900, Ilias Lazaridis <il...@lazari=
dis.com> 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. =A0

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

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

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

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

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. =A0I 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)
> | =A01) without a C-level extension
> | =A02) with a C-level extension
>
> If you don't care about performance, you can investigate
> ObjectSpace#each_object. =A0Note that JRuby turns off the method by
> default for performance reason. =A0

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