Cor v2

Please see the main page of the repo for the actual RFC. As it states there:

Anything in the Wiki should be considered "rough drafts."

Click here to leave feedback

---

There are many things we would love to have in Cor, but we need an MVP (minimum viable product) first. There are several benefits:

• Easier for P5P to agree
• Easier for community buy-in
• Easier to implement
• More likely to get accomplished
• Avoids Jenga architecture

And a final "Jenga" point is a huge one. As anyone working on large projects can tell you, trying to bite off more than you can chew risks building on top of something you shouldn't be building on. For example, if we introduce asynchronous methods in the first pass and we realize that there's a terrible issue with our underlying method implementation or specification, this could be a nightmare to fix. Or it could put us in the position of having to support bad code because too much code depends on it (the Perl SUPER bug being a classic example).

Thus, we strive for an MVP.

Types

Slots

It's unclear if we'll have types in the first iteration. We have currently different possible approaches.

has $foo :isa(Int)

By using our standard attribute syntax, we keep to current Corinna conventions and have a possible extension mechanism. You could possibly write your own types in pure Perl (to be fair, that's basically what objects are). However, if most types are written in Perl, there are concerns about performance penalties. Still, if you company has an internal identifier with is a string of 24 UPPER-CASE hex characters, it might be nice to have:

has $customer_id :isa(OurCompanyID);

has Int $foo; or has $foo Int;

Alternatively, we could go with a more standard type declaration that developers new to Perl might be more familiar with. However, this might limit our extension mechanism because these types are typically built-in types or classes. The custom type syntax above might be hard to support here.

Also, consider this:

$ perl -E 'package Dog {}; my Dog $spot = "Tommy"; say $spot'
Tommy

In the case above, The Dog in the variable declaration is a no-op. By having a similar syntax to that, do we risk confusing developers?

Typed Signatures

Some Corinna examples show types in signatures:

method foo(Str $bar) {
    ...
}

That definitely won't happen because that will step on the work Dave Mitchell is doing for signatures. Plus, it raises the questions about whether or not signatures should be first class and represented in the MOP. We don't have time for that right now. David Mitchell is working on an implementation.

Private methods

Consider this inside of a class:

private method foo () {...}
method bar () {
    my $foo = $self->foo;
    ...
}

Having truly private methods would be very nice, but given that we already need class methods, it stands to reason that we would need private class methods (especially for those involved in object construction). Thus, we'd have:

private shared method init_flux_capacitors() {...}

We suspect that this might be a bit too much for many developers and we probably don't need this for the first pass.

Asynchrony

Everybody and their dog wants asynchronous code and they all want it simulataneously. For the first pass, I recommend we consider syntax akin to what Object::Pad’s async/await.

class Example {
   async method perform ($block) {
      say "$self is performing code";
      await $block->();
      say "code finished";
   }
}

But first, small steps. Small steps.

Exceptions

Having a proper, standard exception syntax will stop the ad-hoc proliferation of exception systems.