New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a set of conventions to minimize impact internal changes to user's code #5780
Comments
From @ajsThe example: class Foo is Hash { has $.blah = 0 }; say Foo.new.blah.perl The output: rakudo-moar 2ef2fd: OUTPUT«Any» Expected output: 0 Reason: Hash defines its own new which bypasses the default handling in Concerns: The code above is not obviously wrong to the user, but is From IRC: [15:09] <harmil_wk> m: class Foo is Hash { has $.blah = 0 }; say -- |
From @ajsHere is a more complete and rigorous example of how this creates substantial problems in library code: https://gist.github.com/ajs/e3a9fb6caf76f23de0940a676ef7dd2b |
From @zoffixznetHere's a link to the above IRC conversation, which continued after the quoted part: https://irclog.perlgeek.de/perl6/2016-11-04#i_13517260 To expand, it's not just Hashes that have this issue; Arrays, SetHash, and Complex also do, and probably many others. And the issue is not just about not setting default values for attributes when instantiating the object, but use of attributes as well. <ZoffixW> m: class Foo does Setty { has %.elems; } Above, if we imagine %.elems as some new internal attribute we added to Setty, you can see it now breaks some user's code. So I think it would be useful to create some sort of convention where we're less likely to impact changes to users' code by making some internal change. For attributes, we can prefix the names with 'rak-' or something short and consistent to mark them as internal. For the .new() issue with Hashes and others, I think lizmat proposed doing something similar to what we do in Date/DateTime classes. |
The RT System itself - Status changed from 'new' to 'open' |
From @ajsAn update: This code shows what low-level classes do not invoke their BUILD submethod when subclassed: https://gist.github.com/ajs/c11a00290b52957a5f686c8ad3c60885 |
From @zoffixznetMore comments on similar issue: https://irclog.perlgeek.de/perl6/2017-09-17#i_15176823 Basically, a lot of core constructs aren't workable with user-land subclasses. |
From @skidsOn Sun, 17 Sep 2017 08:44:47 -0700, cpan@zoffix.com wrote:
Note on the performance concerns... if we had a faster-than-a-where-clause type smiley |
From @lizmat
Technical note: that would mean internally using nqp::eqaddr vs nqp::istype. |
From @zoffixznetSpotted another case where there's impact: whether or not a routine is a multi can have large impact on user's code. For example here: https://stackoverflow.com/questions/48819031/where-did-my-perl-6-operator-go-after-i-defined-a-more-specific-multi/48827522 As part of conventions, we'd need to also figure out what we'll declare as multies and what as onlies. |
From @lizmatI propose we change all onlies in the core to multis after the release and see how this breaks things / makes things slower.
|
From @zoffixznetOn Fri, 16 Feb 2018 05:52:09 -0800, elizabeth wrote:
+1. Let's try. |
From @AlexDanielOn 2018-02-16 09:01:57, cpan@zoffix.com wrote:
Yeah, sounds good. +1 |
Migrated from rt.perl.org#130020 (status was 'open')
Searchable as RT130020$
The text was updated successfully, but these errors were encountered: