Front page | perl.perl5.porters |
Postings from September 2013
Re: [perl #116020] toggle operator missing reset: proposal
Thread Previous
|
Thread Next
From:
tlhackque
Date:
September 5, 2013 18:23
Subject:
Re: [perl #116020] toggle operator missing reset: proposal
Message ID:
5228CBF6.8070608@yahoo.com
On 29-Aug-13 11:49, Zefram via RT wrote:
> tlhackque wrote:
>>> One might imagine a toggle object as a middle ground -- e.g.
>>> $toggle = Toggle::new( '...', sub {/^--a$/} , sub {/^--b$/}); #
> Can be done much more neatly by a call-checker plugin and custom ops.
> I'm thinking of it looking something like
>
> $out .= $_ if toggle /^--a$/, /^--b$/;
>
> Named toggles just need a slight extension to put their state somewhere
> visible. As the hiddenness of a toggle's state is a nasty aspect of
> the core feature, I'd be inclined to make these toggles use an explicit
> variable, whose lifetime can be controlled in the usual ways:
>
> my $tog;
> reset_toggle $tog;
> $out .= $_ if toggle $tog, /^--a$/, /^--b$/;
call-checker plugin?
The problem with an explicit variable is that having a lifetime with the
right semantics is not intuitively trivial.
The current (core) feature is associated with a line of code, not a
recursion level, block scope or closure. Once could put a variable at
file scope, but as previously noted, that's likely to be many lines of
code distant from the point of use.
Without an explicit variable, how do you have instance state? You have
to label the statement (and deal with more than one in a statement -
e.g. toggle1 || toggle2) in order to have a reset operator/function.
Then do you hook the state onto the label? Can a function in the
compiled code find its caller's label?
To me, this seems a lot harder than making the current toggle's state
visible and addressable - and adding a means to reset it. Plus, the
function/object approach ends up with TWO (well, four if you count the
../... variants) operators in the language: the original ops that aren't
resetable, and the new function/objectish ones that have different
semantics (and precedence), but are resetable. So harder doesn't get an
externally pleasing result...even if you make this work.
But I'm not a Perl internals person. From a consumer's point of view,
the current implementation has defined the scope, precedence, behavior
of the operators and has a place where the state lives. All that's
necessary is a way to name that existing state, and a way to apply a
reset operation to that name.
I thought that since any statement can be labeled, a label would be a
good way to name the state - or more precisely, the states since a
statement can have more than one toggle operator. It doesn't require
novel syntax.
But I suppose there are other approaches. condition1 ..('name')
condition2 comes to mind...That allows labeling each operator (even
allowing 'Package::name' to refer to it) rather than hooking on to the
statement label. This might be neater, but I assumed that novel syntax
was the greater barrier.
>>> such as
>>>
>>> reset ['label']; or reset( ['label'], 2 );
> If a toggle reset feature is added to the core, it should not further
> overload an existing core operator, especially one that is presently
> unrelated.
I don't care how the reset function/operator is spelled - the word seems
to have the right sense, and using it avoids adding a new reserved word
to the language. But if it were spelled "/Snuffleupagus/('name')" & had
the desired semantics I'd be happy!
> -zefram
>
>
--
This communication may not represent my employer's views,
if any, on the matters discussed.
Thread Previous
|
Thread Next