Feature #4845
closedProvide Class#cb_object_instantiated_from_literal(object)
Description
(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.
Updated by nobu (Nobuyoshi Nakada) about 13 years ago
- 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.
Updated by lazaridis.com (Lazaridis Ilias) about 13 years ago
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?
Updated by matz (Yukihiro Matsumoto) about 13 years ago
- 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.
Updated by matz (Yukihiro Matsumoto) about 13 years ago
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 ilias@lazaridis.com 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.
Updated by lazaridis.com (Lazaridis Ilias) about 13 years ago
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?
Updated by matz (Yukihiro Matsumoto) about 13 years ago
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 ilias@lazaridis.com 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.
Updated by lazaridis.com (Lazaridis Ilias) about 13 years ago
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 ilias@lazaridis.com 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)?
Updated by lazaridis.com (Lazaridis Ilias) about 13 years ago
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".
Updated by lazaridis.com (Lazaridis Ilias) about 13 years ago
=begin
Follow-up issue #4893
=end