develooper Front page | perl.perl5.porters | Postings from February 2018

Re: [perl #132760] Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz

Thread Previous | Thread Next
From:
Sawyer X
Date:
February 6, 2018 12:26
Subject:
Re: [perl #132760] Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz
Message ID:
69578e00-48db-431c-c609-8fd2f402a555@gmail.com


On 02/06/2018 12:38 PM, Zefram wrote:
> Sawyer X wrote:
>>          It might actually be better to bite the bullet on this and say
>> "Okay, this one case really doesn't work. If you're using lvalue
>> subroutine attribute, you can't return in the signature." and leave it
>> as the much nicer syntax.
> It would be asinine to compromise the functionality for what is at best
> a cosmetic improvement.  (Personally I find it cosmetically neutral,
> so don't agree on it being an improvement in that manner, but even
> the people arguing for it don't ascribe it any more than cosmetic
> value.)  People have decided that the cosmetics trump grammatical and
> structural coherence, but surely the line must be drawn before tangible
> functionality.

What I am reading here is implying that cosmetic changes are
meaningless. Take into account how Catalyst breaks differently if
someone were to introduce a space, from ":CaptureArgs(...)" to
":CaptureArgs (...)". This is cosmetic but will now result in a
completely different error (if at all), which could be quite confusing
to the user. We care about that.

Furthermore, one could also argue that calling return from a signature
serves little purpose and is also a cosmetic difference and is possibly
equally meaningless. Is there any value in returning from a signature
(especially when using :lvalue) which cannot be just as easily
ascertained without?

It's just a wrong place to start the discussion from, IMHO. The more I
spoke with Stevan about this, the more I realized this needs more
thought. I wish more people joined the conversation.

> Not only would current functionality be lost, but also a class of
> potential functionality that we're likely to want to explore. 

Could you expand on this?

Have we ever explored this class of functionality? Where is the
likeliness coming from?

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About