Prev: Method Modifiers
Next: Quotes

---

Section 11: Questions

This file is automatically generated. If you wish to submit a PR, do not edit this file directly. Please edit templates/rfc/questions.md instead. Use bin/generate_rfc.pl to regenerate the RFCs.

---

11.1 Open issues for the RFC

11.1.1 Corinna v Other objects

What would be the easiest way to distinguish between Corinna and other kinds of objects? I think having a base class of OBJECT solves this.

Thus, anyone could simply ask if $thing isa OBJECT and find out of it's Corinna or not. This would be very useful if they want to use the MOP and discover it doesn't work on a regular blessed reference.

11.1.2 Multiple Variables Types In A Field

Can fields have more than one kind of variable?

field ($x, @y);

If so, do we disallow attributes?

11.1.3 Twigils?

field $:x;

method inc ($x) {
    $:x += $x;
}

Pros:

• You can't accidentally shadow class/instance data.
• Great Huffman encoding for "this is not a regular variable"
• Easy to syntax highlight

Cons:

• No direct parser support for twigils
• Is somewhat controversial
• May contribute to "line-noise" complaints

11.1.4 Overridding Fields

A method can override a parent method explicitly to avoid a warning:

method move($x,$y) :overrides {...}

Should methods generated via field attributes be allowed to override parents? If so, how do we signal this?

11.1.5 can, does, and isa

It has been suggested that we offer new versions of can, does, and isa. They would not take arguments.

• can: returns all methods the current class can do (including inherited)
• does: returns all roles the current class does
• isa: returns the iteheritance list

Because these methods currently do not take arguments, this might be extending them instead of modifiying them. However, this would still be modifying current behavior. Or we could put this in an OBJECT base class for Corinna. However, this would mean the external behaviors would be different for Corinna and other objects.

I think this is probaby out of scope for Corinna.

11.1.6 Inline POD?

Because we need a postfix block, many people will be disappointed that we won't have inline POD quite as neat as what we had:

class Foo {

=head1 METHODS

=head2 C<bar>

This method does something

=cut

    method bar() { ... }
}

---

Prev: Method Modifiers
Next: Quotes