Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign uptoggle operator missing reset: proposal #12632
Comments
This comment has been minimized.
This comment has been minimized.
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
|
This comment has been minimized.
This comment has been minimized.
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"> -- |
This comment has been minimized.
This comment has been minimized.
The RT System itself - Status changed from 'new' to 'open' |
This comment has been minimized.
This comment has been minimized.
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:
|
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
From zefram@fysh.orgtlhackque wrote:
Can be done much more neatly by a call-checker plugin and custom ops. $out .= $_ if toggle /^--a$/, /^--b$/; 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 |
This comment has been minimized.
This comment has been minimized.
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 -- |
This comment has been minimized.
This comment has been minimized.
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
-- |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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')
-- |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
From zefram@fysh.orgThere's a consensus against adding anything to the core here. This ticket -zefram |
This comment has been minimized.
This comment has been minimized.
@cpansprout - Status changed from 'open' to 'rejected' |
Migrated from rt.perl.org#116020 (status was 'rejected')
Searchable as RT116020$