Re: goto and @_

Thanks Paul!

Not quite sure I like this very single-use function (where else might
people try to call it and how will this go wrong?), but I have no better
suggestion.

While we're at it, I know you've discussed multi subs and this is even more
interesting to me now (even though I've always favored the idea).

I had this code:

            $method => sub ( $self, $value = undef ) {
                _debug( "Args for overloaded reader/writer for $name", \@_
);
                return @_ == 1
                  ? $self->$reader_method
                  : $self->$writer_method($value);
            }

But haarg pointed out that the intent was for @_ to go away in signatured
subs. This was the best I could think of:

            $method => sub ( $self, @value ) {
                _debug( "Args for overloaded reader/writer for $name", [
$self, @value ] );
                return @value == 0
                  ? $self->$reader_method
                  : $self->$writer_method(@value);
            }

I'm not passing an array or a list as the second argument. Instead, I'm
stuck pretending that I am and I should have a check for @value having more
than 1 argument. In short, variadic subs aren't handled well by signatures.
If we had multidispatch, much of this ugliness would go away:

    sub some_method :multi ($self) { ... }
    sub some_method :multi ($self, $new_value) { ... }

But that doesn't address how I'd create an anonymous multisub.

So far, I'm loving signatures, but now that I'm converting some code to
deal with the impending removal of @_, I'm less convinced.

Now that I think about it, with a decent introspection mechanism for sub
arguments (including the ability to set them), the tailcall issue would
also go away (and the potential bugs of a single-use function with it)
*and* the
code I just wrote would be much cleaner. I hate @_ because it's just more
punctuation to confuse new developers, but it does what it's supposed to do
quite well. I'm open to suggestions.

Best,
Ovid

On Fri, Jun 3, 2022 at 9:19 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Fri, 3 Jun 2022 18:50:19 +0200
> Ovid <curtis.poe@gmail.com> wrote:
>
> > Is there a plan for this?
>
> Ish.
>
> It's known and noted that tailcalls don't work with "no snails"
> currently.
>
> I have thoughts on adding a `tailcall` to address it, so your code
> would become:
>
>     use SOMETHING 'tailcall';
>
>     sub import ( $class, @args ) {
>         my $real_import = get_real_import();
>         # do stuff
>         tailcall $real_import->( $class );
>     }
>
> Quite where that comes from I don't know. It can't just be a `builtin`
> because it's not just a regular function. It'd have to be something
> else - maybe a `use feature` or somesuch.
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
>


-- 
Curtis "Ovid" Poe
--
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/

• goto and @_ by Ovid
• Re: goto and @_ by Dave Mitchell
• Re: goto and @_ by Branislav Zahradník
• Re: goto and @_ by Branislav Zahradník
• Re: goto and @_ by Dave Mitchell
• Re: goto and @_ by Paul "LeoNerd" Evans
• Re: goto and @_ by Ovid
• Re: goto and @_ by Graham Knop