On Wed, May 25, 2016 at 06:32:06PM +0200, Vincent Pit (VPIT) wrote: > >> >> I agree with removing indirect object notation examples given in core >> documentation. If anyone strongly objects to removing examples from the >> perspective Abigail originally provided ("Seeing it is knowing it >> exists"), we can keep it in some cases with a comment saying direct >> methods should be used instead. >> >> Regarding the "indirect" pragma, I believe last time I saw a >> significant reduction in speed, which I think should at least be >> revisited in any future suggestion of implementing it in core. Off-hand, >> I don't see a particular problem with providing it with a "use 5.x" >> pragma statement. I would be happy to see a discussion around the topic >> before any decisions are reached. >> > > What performance hit are you talking about? indirect.pm acts purely at > compile time, so unless your code relies on a lot of eval()s, the impact > on performance is minimal - but then you're already screwed > performance-wise anyway. > > Even if that's not the topic of this thread, I will reiterate that I > would strongly object to incorporating the current implementation of > indirect in core. That's not the way you should do it when you can just > hack into the parser. I'd argue it doesn't belong in core. At all. The reason is it's limited usefulness. People who want to use indirect object syntax certainly won't start their programs with 'no indirect'. It's only useful for people who don't want indirect object syntax in their programs, but somehow use it anyway. I don't think there's much code which will benefit from it, and the amount of code will dwindle over time. AbigailThread Previous | Thread Next