Feature #4845: Provide Class#cb_object_instantiated_from_literal(object)

• Status: Rejected
• Assignee: matz (Yukihiro Matsumoto)
• Target version: -

[lazaridis.com (Lazaridis Ilias)]

(assuming that this is not a bug, but a speed tradeoff / known issue)

class String
alias_method :orig_initialize, :initialize
def initialize(val)
orig_initialize "OBSERVED: " + val
end
def my_method_test
print self.inspect, " test\n"
end
end

oo_string = String.new("The OO String")
li_string = "The Literal String"

print "Class: ", oo_string.class, " - content: ", oo_string, "\n"
print "Class: ", li_string.class, " - content: ", li_string, "\n"
oo_string.my_method_test
li_string.my_method_test

#OUTPUT
#=> Class: String - content: OBSERVED: The OO String
#=> Class: String - content: The Literal String
#=> "OBSERVED: The OO String" test
#=> "The Literal String" test

The li_string is an object of class String and responds to the added method "my_method_test".

But: the initialize method of the modified String class was not called during instantiation.

Is there any chance that this will be changed, thus the "initialize" method is called (if implemented)?

If not, the suggestion would be:

• provide a call-back Class#cb_object_instantiated_from_literal(object) (or similar)

Benefits:

• minimal overhead if not used (C-level if *ptr available, call)
• allows simple notification about new objects.

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Assigned
• Assignee set to matz (Yukihiro Matsumoto)
• Priority changed from Normal to 3

• minimal overhead if not used (C-level if *ptr available, call)

Not true.

[lazaridis.com (Lazaridis Ilias)]

Nobuyoshi Nakada wrote:

• minimal overhead if not used (C-level if *ptr available, call)

Not true.

I admit I don't know your current implementation.

Can you please point me to the relevant source code?

And please rethink the "priority: low" of this issue.

It seems to me that I have no way to intercept (literal) object instantiation.

Or is there any way to do so?

[matz (Yukihiro Matsumoto)]

• Status changed from Assigned to Rejected

Besides that, I strongly discourage to intercept literal creation, since it would change the semantics of the fundamental object model.

matz.

[matz (Yukihiro Matsumoto)]

Hi,

In message "Re: [ruby-core:36809] [Ruby 1.9 - Feature #4845] Provide Class#cb_object_instantiated_from_literal(object)"
on Tue, 7 Jun 2011 18:42:34 +0900, Lazaridis Ilias [e-mail] writes:

|Nobuyoshi Nakada wrote:
|> > * minimal overhead if not used (C-level if *ptr available, call)
|>
|> Not true.
|
|I admit I don't know your current implementation.
|Can you please point me to the relevant source code?

Method invocation is far slower than C function call. And most of the
time was spent in method look-up. So checking existence of
cb_object_instantiated_from_literal (that requires method look-up)
would have huge performance impact.

						matz.

[lazaridis.com (Lazaridis Ilias)]

Yukihiro Matsumoto wrote:

Besides that, I strongly discourage to intercept literal creation, since it would change the semantics of the fundamental object model.

Discouraging and disabling are two different things.

The fundamental object model does not distinguish between "objects" and "literal_objects".

The code demonstrates in a simple manner: the created object is of class String, but is treated differently which means essentially that the OO model breaks.

Currently, I am unable to implement a unique way to handle all my string objects (or other objects which are instantiated via literals).

Is there any workaround available?

[matz (Yukihiro Matsumoto)]

Hi,

In message "Re: [ruby-core:36822] [Ruby 1.9 - Feature #4845] Provide Class#cb_object_instantiated_from_literal(object)"
on Tue, 7 Jun 2011 23:32:31 +0900, Lazaridis Ilias [e-mail] writes:

|Yukihiro Matsumoto wrote:
|> Besides that, I strongly discourage to intercept literal creation, since it would change the semantics of the fundamental object model.
|
|Discouraging and disabling are two different things.

I know. But the performance problem and above discouragement make
me feel it's not worth adding.

						matz.

[lazaridis.com (Lazaridis Ilias)]

Yukihiro Matsumoto wrote:

Hi,

In message "Re: [ruby-core:36822] [Ruby 1.9 - Feature #4845] Provide Class#cb_object_instantiated_from_literal(object)"
on Tue, 7 Jun 2011 23:32:31 +0900, Lazaridis Ilias [e-mail] writes:

|Yukihiro Matsumoto wrote:
|> Besides that, I strongly discourage to intercept literal creation, since it would change the semantics of the fundamental object model.
|
|Discouraging and disabling are two different things.

I know. But the performance problem and above discouragement make
me feel it's not worth adding.

I understand.

But the central point should be: the OO model (consistency) breaks essentially.

I feel uncomfortable to ask a 3rd time, thus I assume that for now there is no workaround available. Can you please confirm?

As for the performance problem:

I've shown my interest to look into this, but the issue was rejected immediately.

I could look into this and could possibly provide a suggestion which has no speed trade-offs. Just please, can you point me to the relevant source code location(s)?

[lazaridis.com (Lazaridis Ilias)]

Please reconsider this issue independent of the given context (in it's general context of implementing an event which reports object creation).

I can file a new issue, but the essence would be the same:

Getting (on request, e.g. when subscribing to an event) a notification about "object was instantiated, by "new", by "literal", by "xyz".

[lazaridis.com (Lazaridis Ilias)]

=begin
Follow-up issue #4893
=end