Method Modifiers Outside of MooseX::Declare about method-signatures HOT 8 CLOSED

Hmmmm ... I think this would be tricky. MSM hooks into the MXD parser and uses it to trigger when to fire. Without MXD, your

around foo (Int $bar) { }

typically becomes

around 'foo' => sub { }

Now, you could certainly do something like:

around 'foo' => method (Int $foo) { }

except that now MS has absolutely no clue that it needs to deal with $orig. So we'd have to make MSM understand how to parse around outside of MXD ... but then of course it has no way to enforce that you don't do an around outside of any class, and--even worse--it doesn't have any way to get access to the current class being parsed. Perhaps simply using __PACKAGE__ might work ... ?

It would certainly be non-trivial, and I'm not sure when I'd have the opportunity to look at it, unfortunately.

Dare I ask: why oh why would you remove all that lovely MXD goodness? :-)

from method-signatures.

You know I'm a fan of MXD :-) Still it makes the simulation I'm presenting rather slower than it needs to be and for PAUSE indexing sake it seems the most prudent. Who knows, perhaps I'm just being silly, but I thought I would try. The truth is, this module didn't use too much of the MXD-ness anyway.

As to around, a very evil thing might be

around 'foo' => method ($orig: $self, ... ) { }

hmmmm, that looks yucky!

from method-signatures.

Still it makes the simulation I'm presenting rather slower than it needs to be ...

I'd be very surprised if removing MXD gained you any run-time speed. Compile-time speed I could see, but I don't know that MXD does anything at run-time. And, actually, if you remove the MXD-ness and forget to add all your make_immutable calls back in, you should see a significant slow-down. ;->

But, hey: try the experiment. I'd be curious to see the profiling results.

... and for PAUSE indexing sake it seems the most prudent.

Not sure I followed that bit.

The truth is, this module didn't use too much of the MXD-ness anyway.

Every single class statement you use saves you a minimum of two lines of code (the autoclean and the make_immutable), not to mention providing a very clear indication of where the class ends (a small thing, but something that makes me absolutely crazy when trying to read "regular" Moose code containing multiple classes). So I think you're getting plenty of MXD goodness no matter what. ;-> But that's just my opinion, obviously. Take it as you will.

As to around, a very evil thing might be

Well, if you're willing to do that, normal old MS should work fine. Although I have to say ...

hmmmm, that looks yucky!

... yeah, that. :-D

from method-signatures.

I'd be very surprised if removing MXD gained you any run-time speed. Compile-time speed I could see, but I don't know that MXD does anything at run-time.

Of course you're right, the actual running time of code I'm running is very quick, so compile-time speed is very noticeable. And I agree, my code looks a lot messier to my eyes too. Perhaps a rollback is in order.

I had forgotten that there is a dzil plugin for indexing MXD correctly, so this shouldn't be a big problem for that; assuming I go back to dzil. (https://github.com/jberger/Physics-RayTransfer/blob/master/dist.ini#L19)

from method-signatures.

Of course you're right, the actual running time of code I'm running is very quick, so compile-time speed is very noticeable.

Well, that's fair comment. I never tried to determine how much MXD added to compile-time. Might be an interesting blog post, if you could figure out a way to profile that.

And I agree, my code looks a lot messier to my eyes too. Perhaps a rollback is in order.

Well, far be it from me to try to tell you how to do your releases, but I can't help but think that the more legibile your code looks, the better that reflects on you as the author. ;->

I had forgotten that there is a dzil plugin for indexing MXD correctly, so this shouldn't be a big problem for that; assuming I go back to dzil. (https://github.com/jberger/Physics-RayTransfer/blob/master/dist.ini#L19)

Ah, yes, I see what you mean now. It's also possible to specify that explicitly, of course, but that dzil plugin is a good call. One day, I plan to collect all those such things and put them in a bundle or Task:: or somesuch to make using MXD much easier. I'll jot this one down for inclusion in that.

from method-signatures.

Joel, are you happy with the answers here? Can I close the issue?

from method-signatures.

While I still think it might be an interesting long-term idea, it isn't a practical one in the short term. Work on something more useful!

from method-signatures.

Understood. Thanx. :)

from method-signatures.