Forum: IronRuby Strange behavior when redefining methods on object instances (possible bug)

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
1c29f9b1bf5f1b88ed8b0c9a9be39788?d=identicon&s=25 Daniele Alessandri (Guest)
on 2009-04-22 14:44
(Received via mailing list)
Hi,
while in the process of trimming down the failure rate of the
core/array specs I noticed a strange behavior of IronRuby. I'm pasting
here two repl sessions I used to reproduce it:

    >>> foo = Object.new
    => #<Object:0x000005c>
    >>> bar = Object.new
    => #<Object:0x000005e>
    >>>
    >>> def foo.to_s; p "foo#to_s has been invoked"; "foo" end;
    => nil
    >>>
    >>> foo
    "foo#to_s has been invoked"
    => foo
    >>> bar
    => #<Object:0x000005e>

As you can see there is nothing wrong here, so here is the second
session where the only difference is in that the order of foo and bar
at the end of the snippet is inverted:

    >>> foo = Object.new
    => #<Object:0x000005c>
    >>> bar = Object.new
    => #<Object:0x000005e>
    >>>
    >>> def foo.to_s; p "foo#to_s has been invoked"; "foo" end;
    => nil
    >>>
    >>> bar
    => #<Object:0x000005e>
    >>> foo
    => #<Object:0x000005c>

I would expect to get "foo#to_s has been invoked" printed just like in
the first snippet (and IRB on MRI behave like expected), but instead
the method called on foo is the one of Object#to_s (a step-by-step
debug session confirmed this). Could it be related to some issues in
the method caching stuff that happens deep into the internals of
IronRuby?

This problem affects certain mocking scenarios when running mspec (eg.
"Array#== returns false if any element is not == to the corresponding
element in the other the array" and "Array#delete removes elements
that are #== to object", but their implementation looks ok to me), so
it might even be possible that more specs which are being reported as
failures are not related to bogus implementations, but it is just
mspec that is failing due to a bug.

Is there anyone that can confirm this before I file a bug on the bug
tracker?

Thanks,
Daniele

--
Daniele Alessandri
http://www.clorophilla.net/blog/
http://twitter.com/JoL1hAHN
Cb51033949ffccd982ae32c9f890f25a?d=identicon&s=25 Tomas Matousek (Guest)
on 2009-04-22 17:56
(Received via mailing list)
Please file a bug.

Thanks,
Tomas
1c29f9b1bf5f1b88ed8b0c9a9be39788?d=identicon&s=25 Daniele Alessandri (Guest)
on 2009-04-23 20:31
(Received via mailing list)
Bug report filed here:
http://ironruby.codeplex.com/WorkItem/View.aspx?Wo...

Thanks,
Daniele

On Wed, Apr 22, 2009 at 17:37, Tomas Matousek
<Tomas.Matousek@microsoft.com> wrote:
>
>    >>> def foo.to_s; p "foo#to_s has been invoked"; "foo" end;
> at the end of the snippet is inverted:
>    => #<Object:0x000005e>
> This problem affects certain mocking scenarios when running mspec (eg.
> Daniele
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core@rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>



--
Daniele Alessandri
http://www.clorophilla.net/blog/
http://twitter.com/JoL1hAHN
This topic is locked and can not be replied to.