On Sat, Nov 04, 2006 at 08:46:37PM +, Jonathan Worthington wrote:
> Jonathan Worthington wrote:
> >At the moment, if you have some ParrotObject instance, say foo, and do
> >something like:
> >
> > $S0 = foo
> >
> >Then $S0 will contain the name of the class.
> >
> >=item C
>
> Erm, what the h
Jonathan Worthington wrote:
At the moment, if you have some ParrotObject instance, say foo, and do
something like:
$S0 = foo
Then $S0 will contain the name of the class.
...
=item C
Erm, what the heck was I smoking when I wrote this...the name method
doesn't control what an object stringi
Patrick R. Michaud wrote:
I propose this is removed in a week, please respond if you'd have an
issue with that or think that's too short.
I think it's too long. :-)
Does anything fail if you eliminate it (e.g., via "make tests")?
If no, then I think it's okay to eliminate, and we'll see
On Sat, Oct 28, 2006 at 06:50:05PM +0100, Jonathan Worthington wrote:
> So, I want to get rid of this and allow this v-table method to just
> dispatch to a user implementation or a fallback. But before I do that, I
> wanted to check if anyone is relying on the behavior? I'd really rather
> not b
Hi,
At the moment, if you have some ParrotObject instance, say foo, and do
something like:
$S0 = foo
Then $S0 will contain the name of the class. This is BAD because it
means you can't overload what a class stringifies too! In fact, there is
a comment in the code saying that:
/*
=item C
