Re: Anyone relying on objects stringifying to class names?
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 heck was I smoking when I wrote this...the name method > doesn't control what an object stringifies to at all. I managed to read > it as get_string. :-( > > Sorry 'bout that. And while this is marked as being bad in the comment, > I can't remove it since it's used (and I'm not even sure, how bad it is > now). PGE uses it for example. Hmm, I can't recall where PGE might be using this -- could you point to an example so I can make sure it's relatively sane? Thanks, Pm
Re: Anyone relying on objects stringifying to class names?
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 stringifies to at all. I managed to read it as get_string. :-( Sorry 'bout that. And while this is marked as being bad in the comment, I can't remove it since it's used (and I'm not even sure, how bad it is now). PGE uses it for example. D'oh. Jonathan
Re: Anyone relying on objects stringifying to class names?
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 if anyone carps about it. But that's just my $0.02. A week's notice seems fair. Then if all the tests pass, nuke it! :) Allison
Re: Anyone relying on objects stringifying to class names?
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 break working code without giving folks a chance to fix it, but this > behavior needs to die. I'm amazed, nobody has killed it already. > > 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 if anyone carps about it. But that's just my $0.02. Pm
Anyone relying on objects stringifying to class names?
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 Shortcut for .class().name() XXX - this is bad and should go =cut */ 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 break working code without giving folks a chance to fix it, but this behavior needs to die. I'm amazed, nobody has killed it already. I propose this is removed in a week, please respond if you'd have an issue with that or think that's too short. Thanks, Jonathan
