Re^3: RFC: "assignary" operator ?= :

> not ternary, just "binary",

yes it's binary.

> $var1 ?= die "ERROR: \$var1 already set." : $var2;

Thanks for demonstrating your use case, it's even stranger than I expected! ;-)

die will not return a value - actually it won't return at all.

> Maybe you'll see more elegant way how to do such thing.

Yes with a properly named custom-function operating on an alias.

something like

 
sub init { 
   die "ERROR: \$var already set." if defined $_[0];
   $_[0] = $_[1];
}

init $var1 => 'value1';  # pretty elegant, right?
init $var2 => 'value2';
init $var3 => 'value3';
[download]

Please note the defined° , cause else wise you'd miss false values like 0 or "". (which renders your requirement for a new operator a bit useless)

UPDATE:

if you need the proper $var name use PadWalker
use Carp to report from the perspective of the caller

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery
FootballPerl is like chess, only without the dice}

~~°) a shorter way would have been $_[0] // die 'ERROR: ...';~~

Off by one, it's the inverted case :)

Comment on Re^3: RFC: "assignary" operator ?= : Select or Download Code

Replies are listed 'Best First'.
Re^4: RFC: "assignary" operator ?= : by shmem (Chancellor) on Dec 07, 2019 at 17:38 UTC
Yes with a properly named custom-function operating on an alias. `init $var1 => 'value1'; # pretty elegant, right?` [download] No, not at all. First, `init()` is a poor name which doesn't, by name, tell at all what it is doing. Second, the sub you wrote isn't at all ternary in any way, since it misses `$_[2]`. Third and last, `function LIST` doesn't tell at first glance that it is about conditional assignment to `$_[0]` from either `$_[1]` or `$_[2]` based on defined-ness of `$_[0]`. perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'	[reply] [d/l] [select]
Re^5: RFC: "assignary" operator ?= : by LanX (Saint) on Dec 07, 2019 at 18:01 UTC
> Second, the sub you wrote isn't at all ternary in any way It's an XY problem, the use case wasn't ternary from the beginning. But you're welcome to impress us with a better solution. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply]
Re^4: RFC: "assignary" operator ?= : by richard.sharpe (Sexton) on Dec 07, 2019 at 22:13 UTC
Thank you, Rolf (and also other guys). Personally I'd prefer for such "basic thing" something "exactly explicit" just where it's used, without packaging/hiding it in the subroutine defined elsewhere. I prefer using custom subroutines for bit less simple logic (just personal preference). About no return from dying: yes, I really don't need returning from that death, therefore I called that "exploiting". But maybe somebody will find also other use cases for such "assignary" operator, not just this one. In the context of my practise (as used in my scripts and modules), I initialize (define) all my local variables just with heir `my`, to be more explict, what type of value are they predetermined to bear (number, string, hashref, etc.), e. g.: `my $string = '';` and therefore I don't need to differentiate `undef` from `''`, which means "not set" in my example. But, in case, of undefined variable used in assignary, e.g.: `my $some_undefined_var; $some_undefined_var ?= die 'already set' : 'survived';` on my opionion, it could stay alive, and "use of uninitialized value" warning raised on `use warnings;`.	[reply] [d/l] [select]


We don't bite newbies here... much
	PerlMonks