Front page | perl.perl5.porters |
Postings from September 2013
tlhackque wrote: >call-checker plugin? See L<perlapi/cv_set_call_checker>. It's a mechanism that allows an XS module to completely transform the op tree resulting from parsing a subroutine call. The "toggle $tog, /^--a$/, /^--b$/" expression parses as a call to the toggle() sub, provided there is such a sub in scope. A call checker attached to the sub can then replace the sub call with an op tree that uses the argument ops in a different way. >The problem with an explicit variable is that having a lifetime with >the right semantics is not intuitively trivial. A "state" variable gives you the whole-program lifetime that you get for the state of a built-in toggle. That's only rarely the best scope to use, but it's there if you want it. It looks like you want this scoping (or think you want it) just because it's what the built-in feature does. Most of your cases for resetting toggles would probably be better handled by having a separate instance of the state variable per invocation of some function, which you could get with a "my" variable. >Without an explicit variable, how do you have instance state? A call checker can introduce implicit variables if it wants to. If they're "state" variables, they'll act exactly like the implicit state of built-in toggles. >have to label the statement (and deal with more than one in a >statement - e.g. toggle1 || toggle2) That's a good reason why the labels on statements are not a good approach to linking reset operations to toggle expressions. Another good reason is that statement labels are designed to be resolved at runtime, whereas this feature makes more sense with compile-time resolution. Some of the other issues you list are also problems that only arise if you attempt to use statement labels for this. The great thing about using ordinary variables to hold state is that the whole mechanism already exists, with sensible semantics and a lot of flexibility. >To me, this seems a lot harder than making the current toggle's state >visible and addressable The problems with using statement labels would apply regardless of whether it's a new module implementation or a modification of the built-in toggles. > This might be neater, but I assumed that novel >syntax was the greater barrier. Novel syntax (both here and for the reset operator) is less of a problem than using a semantic feature for a purpose for which it is not suitable. But overall there's some resistance to adding *any* substantive feature to the core that could be implemented as a module. -zeframThread Previous | Thread Next