Hi all,
Recently Nick wrote that before we send an RFC, we should send what I think of as "an RFC for an RFC":
> 1: Here is a problem> 2: Here is the syntax that I'm proposing
> 3: Here are the benefits of this
> 4: Here are potential problems
The following is deliberately brief as I know many of you are familiar, at least roughly, with the Corinna project, but it's hard to summarize something this large. Further, we've been stripping everything out of the MVP that we think we reasonably can, but still, this is not as brief as what Nick asked for. (Nick, I still might have that photo of you with a tea cozy on your head at OSCON, so be kind).
1. The problem
We need modern OO in the Perl core. Myself, Paul Evans, and many other people have contributed to the following, but I take full responsibility for any idiocy.
Inside the echo chamber: "It's so easy to do X in Perl that there's no need to add X to core."
Outside the echo chamber: "Perl's missing many features that modern languages need."
This is hurting us and we're losing developers and jobs as a result.
2. The syntax
This limited example shows a simplistic LRU cache (not showing roles):
use feature 'class';
class Cache::LRU v0.1.0 {
use Hash::Ordered;
has $cache :handles(qw/exists delete/) = Hash::Ordered->new;
has $max_size :new :reader = 20;
has $created :reader = time;
method set ( $key, $value ) {
if ( $self->exists($key) ) {
$self->delete($key);
}
elsif ( $cache->keys > $max_size ) {
$cache->shift;
}
$cache->set( $key, $value ); # new values in front
}
method get($key) {
if ( $self->exists($key) ) {
my $value = $cache->get($key);
$self->set( $key, $value ); # put it at the front
return $value;
}
return;
}
}
3. The benefits:
- Compile-time failure of misspelled slots/attributes
- Proper encapsulation
- Solves Perl's version of "The Lisp Curse" http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
- Many others!
-
This has been over two years of work, though initial work wasn't public until October of 2019. Since then, many, many people have contributed to make the design better and Paul Evans release Object::Pad, a test bed for many of the ideas (one that's powerful enough that it's already being used in production).
4. The potential problems:
For older Perl's, if you have a single instance or class variable in your class, you get a compile-time failure if you're using strict. Otherwise, you get weird runtime failures due to indirect object syntax. We're compatible with older Perl's in that the code won't run, but there are a few unusual cases which can be constructed (for example, reusing existing package names) which would prove confusing, but we are hoping this will be minimal and the risks worth the reward. For reasonable Perl code bases (stop laughing), we feel we're good to go.
I've been doing most of the design and Paul Evans has been doing most of the implementation. Many members of the Perl community (https://github.com/Ovid/Cor/wiki/Contributors) have been improving the design by pointing out weaknesses I've missed.
5. Not asked for, but ...
We don't plan to send the RFC for a while. Instead, this is a sounding board for your receptiveness to it. We're still working on the RFC because, while Paul's already finished much of the implementation, we don't feel rushing this is a good idea. Hence, over a year and a half between first announcement and this email (and over two years since development started).
Best,Ovid
-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/.
Buy my book! - http://bit.ly/beginning_perl
Recently Nick wrote that before we send an RFC, we should send what I think of as "an RFC for an RFC":
> 1: Here is a problem> 2: Here is the syntax that I'm proposing
> 3: Here are the benefits of this
> 4: Here are potential problems
The following is deliberately brief as I know many of you are familiar, at least roughly, with the Corinna project, but it's hard to summarize something this large. Further, we've been stripping everything out of the MVP that we think we reasonably can, but still, this is not as brief as what Nick asked for. (Nick, I still might have that photo of you with a tea cozy on your head at OSCON, so be kind).
1. The problem
We need modern OO in the Perl core. Myself, Paul Evans, and many other people have contributed to the following, but I take full responsibility for any idiocy.
Inside the echo chamber: "It's so easy to do X in Perl that there's no need to add X to core."
Outside the echo chamber: "Perl's missing many features that modern languages need."
This is hurting us and we're losing developers and jobs as a result.
2. The syntax
This limited example shows a simplistic LRU cache (not showing roles):
use feature 'class';
class Cache::LRU v0.1.0 {
use Hash::Ordered;
has $cache :handles(qw/exists delete/) = Hash::Ordered->new;
has $max_size :new :reader = 20;
has $created :reader = time;
method set ( $key, $value ) {
if ( $self->exists($key) ) {
$self->delete($key);
}
elsif ( $cache->keys > $max_size ) {
$cache->shift;
}
$cache->set( $key, $value ); # new values in front
}
method get($key) {
if ( $self->exists($key) ) {
my $value = $cache->get($key);
$self->set( $key, $value ); # put it at the front
return $value;
}
return;
}
}
3. The benefits:
- Compile-time failure of misspelled slots/attributes
- Proper encapsulation
- Solves Perl's version of "The Lisp Curse" http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
- Many others!
-
This has been over two years of work, though initial work wasn't public until October of 2019. Since then, many, many people have contributed to make the design better and Paul Evans release Object::Pad, a test bed for many of the ideas (one that's powerful enough that it's already being used in production).
4. The potential problems:
For older Perl's, if you have a single instance or class variable in your class, you get a compile-time failure if you're using strict. Otherwise, you get weird runtime failures due to indirect object syntax. We're compatible with older Perl's in that the code won't run, but there are a few unusual cases which can be constructed (for example, reusing existing package names) which would prove confusing, but we are hoping this will be minimal and the risks worth the reward. For reasonable Perl code bases (stop laughing), we feel we're good to go.
I've been doing most of the design and Paul Evans has been doing most of the implementation. Many members of the Perl community (https://github.com/Ovid/Cor/wiki/Contributors) have been improving the design by pointing out weaknesses I've missed.
5. Not asked for, but ...
We don't plan to send the RFC for a while. Instead, this is a sounding board for your receptiveness to it. We're still working on the RFC because, while Paul's already finished much of the implementation, we don't feel rushing this is a good idea. Hence, over a year and a half between first announcement and this email (and over two years since development started).
Best,Ovid
-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/.
Buy my book! - http://bit.ly/beginning_perl