I'm not sure if any of the following comments will be helpful or not as they are based only upon what I think I understand of A12.

The first and most significant feeling I get from reading (and re-reading) A12 is that there are at several levels of information contained within the document as a whole, and these levels can (roughly) be segregated into that which is of interest to four different types of people:

1. Class user.
2. Class writer.
3. Language parser implementer.
4. Language interpreter/compiler implementer.

Obviously, there are grey areas and overlaps between these notional categories, and many individuals will wear different hats at different times. In LW's case, he has to wear all four simultaneously, at least to some degree.

Also present are several "or something like that"s and similar, less-than-definitive addendums. Many of which are for amusement, but enough are not clearly so, that it leaves me wondering if there is something I've not quite followed.

Personally, the problem I am having is trying to visualise

1. Quite how I will do those things that I know I will need to do. Whether when just using an existing class or when designing a class.
2. Quite how, but more importantly why, I will use some of the features that I am not yet very familiar with.

   An example:

   Traits, Roles, and interfaces.

   The term "trait" first comes up under the heading "Class Composition with Roles" in reference to the "Traits paper". However, later on Traits are discussed as being different from Roles in as much as (if I've understood it correctly); Roles do thing for a class, whereas Traits do things to a class.

   But, a well behaved trait is the same (or very similar?) to a Role. And Roles, without implementation degenerate to Interfaces.

   Traits can be applied to a class using is (which also can apply both Roles and Interfaces and inheritance?), but can also be applied using trait verbs, which appear to be superficially similar to properties?

   That probably serves only to show how confused I am, and this isn't a request for clarification of my personal (current) misunderstandings--hopefully I'll work those out over time. My point is that there is a great deal of information going on in this document, and much of the information presented in each section and paragraph is important to different people, and at different times in the development cycle.

Whilst LW and DC have had many months to become familiar with each of the concepts and how they all relate, and have to consider how each piece of syntax works at all levels. I as a potential Class User and maybe Class Writer probably don't need to consider much of it straight away. At least not until I am over the hurdle of learning the syntax. It may well become important later. Much of the "how it works under the covers" information is what I would term "uncomfortable detail" at this point. I get thoroughly lost when reading the stuff about Multiple Dispatch.

I do realise that everything in the paper is necessary for the paper to succeed in addressing all the questions of the very wide, target audience--it must have been very difficult to write.

Speaking personally, I'm having trouble separating the "How do use it" information from the "How it works" and "How it will be implemented". What I would like to see in E12 is a fully worked example.

Documentation is hardly my strong suite, but I think that I would find it easiest to digest if the information was presented in the form of a short--but realistic, workable--example of using a class (small c) hierarchy. Followed by the presentation of the implementation of that class hierarchy that preferably includes a base class, a couple of derived classes, one that uses an incorporates using a Role; the other that uses a Trait; and the definition of both the Role and the Trait. Along with the reasoning why one was used over the other for each.

Finding a good example of each and putting them together into a minimal, but not too cutesy example program would be no mean feat. I've tried a similar task myself in the past.

Anyway, FWIW, that's my thinking having spent the last two days reading and digesting A12. It feels like I am reading something very important, and there are many places where I find myself thinking "Thats brilliant!", but at this stage I am still trying to get to grips with HOW and WHY I would use much of the stuff therein. --HTH

Much of A12 is, as you pointed out, about implementation. To us mere mortals, it's the kind of thing that's interesting to know, but really I didn't try too hard to understand the dispatching details. All I need to know is that I can write methods with the same name and different signatures and it will work. And I barely more than skimmed any paragraph that mentioned an ALLCAPS sub. Things like BUILD, BUILDALL, AUTOMETH, etc., are just kind of vague things that do stuff I probably won't need to change in the near future, if ever.

Roles are more for the Class Writer than the User. They're just little bits of abstracted behavior that you can throw into classes that need the behavior. They're useful to get away from writing lots of abstract classes that just contain behavior and then doing multiple inheritance all over.

As a Class User, you pretty much just do what you do now. As long as the Writer has done their job correctly, you just do:

use SomeClass;

my $obj = SomeClass.new;
$obj.something;
# etc.
[download]

In fact, even deriving from a class that uses Roles doesn't require knowing about them. To your derived class, any methods implemented as Roles in the base class look like any other derived method to your class.

I'm not too sure about Traits, myself, so I'll refrain from commenting on them at all. A good example involving what Traits are and how to use them would be my request for E12.

To me, it is just an unnecessary addition, with a postfix sigil to boot! It doesn't pass Occam's Razor, imho.

I don't understand what the reason is, given that new() is a multimethod

So instead of doing:

print $*OUT: "Howdy, world!\n";
[download]

in Perl 6 you'd prefer

$*OUT->print( "Howdy, world!\n" );
[download]

?

If I created $*OUT as an object, then yes, I would prefer to call the method on it. I don't want to have to remember that I need a colon after it an object reference just because the Perl6 parser needs it to disambiguate between a multimethod and a multisub.

Personally, I always felt that print() (and friends) has a difficult syntax to work with, given that it is different than every other other CORE function.

Frankly, if that syntax is important enough to you, you could just do something like (in Perl5 syntax):

multisub print
{
    my $invocant = shift;

    if (UNIVERSAL::can( $invocant, 'print')
    {
        return $invocant->print(@_);
    }

    print ($invocant, @_);
}
[download]

Now, you treat it just like a regular function, if necessary.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

The syntax you just printed is the preferred method for some languages like Java (i.e. there are no barewords you can use, you have to be very explicit about everything -- unless the method is in schope, which it never is). Personally, I don't like going overboard on Object Orientedness, but I can understand why some people like it, and how it can make the language clearer for some people. All in all, I think it's mostly a matter of personal preference.

---

Want to support the EFF and FSF by buying cool stuff? Click here.

If E12 can help us reduce those years of anarchy, or at least draw a map that marks the known tar pits and dragon's lairs; and perhaps a few friendly inns: that would be most appreciated.

--Dave.

My initial thought is that applications should primarily worry about classes and libraries should primarily provide roles.

Of course, any interesting application above a certain size will produce its own libraries....