New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
toggle operator missing reset: proposal #12632
Comments
From tlhackque@yahoo.comCreated by tlhackque@yahoo.comThis is a bug report for perl from tlhackque@yahoo.com, ----------------------------------------------------------------- This makes its use difficult where the input is external. Consider the case where we want to extract lines from a file This is great, until we encounter a filea that is missing the (last) --b marker. Various work-arounds have been used; typically arranging for an "extra" end marker to be My proposal: So the minimum implemention would permit: Here, reset will initialize every toggle operator in the labeled statement. Extra credit: if the label is indexed, initialize the n'th toggle. E.g. The LABEL has the semantics of A somewhat contrived example: reset TOGGLES[0,2]; TOGGLES: initializes the first and third toggles, but doesn't touch the second. This seems useful, consistent with Perl syntax and yet new syntax that won't break any existing code. I think it would solve this long-standing divot in Perl's semantics. Perl Info
|
From @iabynOn Sat, Dec 08, 2012 at 03:56:33AM -0800, via RT wrote:
but C<reset TOGGLE> currently means the same as C<reset "TOGGLE"> -- |
The RT System itself - Status changed from 'new' to 'open' |
From tlhackque@yahoo.comFair observation. Other syntax would work - pehaps "reset [label]" ? Surely an arrayref is currently a nonsensical argument to reset...which I'm not a Perl internals person, so certainly other ideas will come to I'm just hoping that some variant of this will take someone's fancy who On Mon Dec 10 07:51:43 2012, davem wrote:
|
From zefram@fysh.orgvia RT wrote:
I think the toggle operator is a wart that we should lean towards If you like the toggle behaviour, I suggest that you should implement -zefram |
From @cpansproutOn Wed Aug 28 13:20:25 2013, zefram@fysh.org wrote:
I think I agree here. Shall I close it? What do others think? -- Father Chrysostomos |
From zefram@fysh.orgtlhackque wrote:
Can be done much more neatly by a call-checker plugin and custom ops. $out .= Named toggles just need a slight extension to put their state somewhere my $tog;
If a toggle reset feature is added to the core, it should not further -zefram |
From tlhackque@yahoo.comOn 28-Aug-13 16:20, Zefram via RT wrote:
Although it certainly isn't the most elegant of Perl's operators and The suggestion for a cleaner version in CPAN is interesting; although One might imagine a toggle object as a middle ground -- e.g. Note also that the range (a.k.a toggle) operator can not be overloaded. And so we end up with my original suggestion as the least inelegant reset ['label']; or reset( ['label'], 2 ); Or any other syntax that expresses the semantics but is easier to deal -- |
From tlhackque@yahoo.comOn 29-Aug-13 03:15, Father Chrysostomos via RT wrote:
I responded yesterday, but it didn't seem to get posted. Short form: if The range operator is part of the language, and is undeniably useful I would strongly oppose removing the range operator. And given that it I don't see how CPAN distribution makes the problem simpler: code to As I noted yesterday (quoted below), re-implementing a 'cleaner' version The range [flip-flop] operator isn't pretty - but it is expressive and I don't see a deprecation effort being successful - and it's almost Please focus on what's good for the language's users rather than the
-- |
From @HugmeirOn Thu, Aug 29, 2013 at 12:48 PM, Zefram <zefram@fysh.org> wrote:
Heh. I was about to do a bit of shameless advertisement by saying that "you sub toggle; my $toggle_state = ''; if ( !$toggle_state ) { return $toggle_state; my $out; say $out;
I believe this would "just" require extending the code above to also use
+1 |
From tlhackque@yahoo.comOn 29-Aug-13 11:49, Zefram via RT wrote:
call-checker plugin? The problem with an explicit variable is that having a lifetime with the The current (core) feature is associated with a line of code, not a Without an explicit variable, how do you have instance state? You have To me, this seems a lot harder than making the current toggle's state But I'm not a Perl internals person. From a consumer's point of view, I thought that since any statement can be labeled, a label would be a But I suppose there are other approaches. condition1 ..('name')
-- |
From zefram@fysh.orgtlhackque wrote:
See L<perlapi/cv_set_call_checker>. It's a mechanism that allows an
A "state" variable gives you the whole-program lifetime that you get for
A call checker can introduce implicit variables if it wants to.
That's a good reason why the labels on statements are not a good approach
The problems with using statement labels would apply regardless of
Novel syntax (both here and for the reset operator) is less of a problem -zefram |
From @ikegamiOn Wed, Aug 28, 2013 at 4:19 PM, Zefram <zefram@fysh.org> wrote:
Use of global vars/states keeps getting us into trouble. This would be easy to implement using Devel::CallParser: my $toggle; It's not much more complicated than the existing syntax, and it could allow |
From zefram@fysh.orgThere's a consensus against adding anything to the core here. This ticket -zefram |
@cpansprout - Status changed from 'open' to 'rejected' |
Migrated from rt.perl.org#116020 (status was 'rejected')
Searchable as RT116020$
The text was updated successfully, but these errors were encountered: