Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^3: Recap: The Future of Perl 5

by tobyink (Canon)
on Aug 24, 2018 at 12:06 UTC ( [id://1221019]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Recap: The Future of Perl 5
in thread Recap: The Future of Perl 5

Even with something as simple as Str, if you put ten Perl developers in a room, I'd expect them to have eleven different opinions on how it should be implemented.

my Str $x = $y;
  • If $y is undef, then $x should be "" because of type casting.
  • If $y is undef, then there should be an exception thrown because undef isn't a string.
  • If $y is an overloaded object, then $x should now be an overloaded object.
  • If $y is an overloaded object, then $x should now be the stringified version of that object.
  • If $y is an overloaded object, then there should be an exception thrown because an object isn't really a string and overloading sucks anyway.
  • Even if $y is a non-overloaded object, $x should now be the stringified version of that object.
  • If $y is 42 (no quote marks), then there should be an exception thrown because integers aren't a subset of strings dammit!
  • If $y is 42 (no quote marks), then $x should be "42" (with quotes) and poking around with B:: stuff you should be able to tell the difference between them.
  • A lot of these cases could be handled by using warnings instead of exceptions. It's basically the same kind of error as use warnings "numeric" anyway, and we're happy enough having those be non-fatal.
  • Empty strings are always an error in my application, so if $y is "", it should throw an exception, shut down the computer, and set the building on fire. (In all seriousness, I know of at least one case in Perl where empty strings are special-cased, treating them differently from non-empty strings.)
  • But dualvars! Waaaaaah!

Replies are listed 'Best First'.
Re^4: Recap: The Future of Perl 5
by Ovid (Cardinal) on Aug 24, 2018 at 13:44 UTC

    The point of optional, gradual typing is to offer optional type safety. If I say "String", it must be defined and have an appropriate string value. Thus, undef would cause an exception. I would suggest that any non-overloaded reference would also throw an exception (No more printing out ARRAY(0x7fecea803280)). However, if stringification is directly overloaded, we'd have to respect the intent because printing DateTime->now is intended to work. The integer 42 would need to stringify to 42 because even Java allows this as the one case of operator overloading because it's so damned useful.

    That being said, I could be smoking crack. And I'd want these to be exceptions, not warnings, because I find so many ways in which warnings can be overlooked.

      The point of optional, gradual typing is to offer optional type safety.

      This seems like a tricky feature in an allomorphic language like Perl, where intrinsics are polymorphic and operators are monomorphic.

      I would suggest that any non-overloaded reference would also throw an exception.

      I think there are cases where default stringification is desirable, and I suspect you'd have to go through each operator and each intrinsic to come up with a matrix of where it might be useful. This seems like a similar problem to smart match (though less so, because stringification for types should be a unary op, not a binary op).

Re^4: Recap: The Future of Perl 5
by haj (Vicar) on Aug 24, 2018 at 12:29 UTC

    I'd be quite fine with eleven different opinions on how Str should be implemented. The Perl developers should then talk to each other, look for a consensus and make this the way it is done.

    It is the subtle differences between Perl's (CPAN) object systems which drives me nuts, not the individual behaviour of any of these systems. I can live just fine with any of them, but having more than one in a project, which is inevitable for bigger projects, hurts.

      The Perl developers should then talk to each other, look for a consensus and make this the way it is done.

      Agreed. And since there are already multiple competing modules to handle type constraints and OO in general any Perl programmer could happily ignore anything added to the language and continue to use their existing favourite module because TIMTOWTDI.

      having more than one in a project, which is inevitable for bigger projects, hurts.

      Ain't that the truth. It certainly looks like that particular horse has long since bolted, unfortunately.

        since there are already multiple competing modules to handle type constraints and OO in general

        My main point is that Perl should provide an API for those existing competing modules to hook into the same syntactic sugar within a particular scope. I don't have any problem with there being a core way and alternatives on CPAN.

        The choice is there being multiple type constraint systems which each have their own syntax, or multiple type constraint systems which at least can take advantage of a common syntax.

        Like how Moose, Mouse, Moo, and hand-crafted classes can all use ClassName->new(%params) as their constructor. You can write your constructor differently, like ClassName::get_factory(parameters => \%params)->new_object() but except in unusual circumstances, most people would prefer to ease cognitive load by using the common pattern.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1221019]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (3)
As of 2024-03-28 13:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found