Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

On the Improvement of Exegesis 12

by Anonymous Monk
on Apr 18, 2004 at 08:11 UTC ( #346064=perlmeditation: print w/replies, xml ) Need Help??

I await the upcoming E12 with as much anticipation as I did A12. And while I am aware that it will be at least a couple months before we see it, I wanted to make sure no one would miss this by TheDamian and quoted here in full:
Hmmmmmm. Given that Larry and the rest of us worked very hard to design a syntax and semantics that specifically *improves* the maintainability of OO Perl code, we'd certainly appreciate feedback on those bits you feel will still be total nightmares to maintain. If nothing else, I'd like to get a handle on what people are troubled by in A12, so I can better address their concerns in E12.

Anyhow I felt it deserved to be a top level node. (so it would be easier to follow the public feedback, in at least this forum.)

Edited by Chady -- fixed TheDamian link.

Replies are listed 'Best First'.
Re: On the Improvement of Exegesis 12
by BrowserUk (Patriarch) on Apr 18, 2004 at 22:16 UTC

    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

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail

      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 =; $obj.something; # etc.
      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.

Get rid of the Indirect Syntax, please!
by dragonchild (Archbishop) on Apr 18, 2004 at 16:13 UTC
    I mentioned this to Larry when he was drafting A12, but I don't like the indirect syntax. I never have, primarily because I don't understand what the reason is, given that new() is a multimethod.

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

    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

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

      So instead of doing:

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

      in Perl 6 you'd prefer

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


        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, @_); }

        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.
Re: On the Improvement of Exegesis 12
by dpuu (Chaplain) on Apr 18, 2004 at 21:47 UTC
    I think the challenge I see is to explain how to approach an application. Is an application a collection of cooperating classes; or is it a collection of cooperating roles (the fact that cooperation is via composition into classes being secondary). We know people went mad with inheritance when OOP first came along. We learned, through pain and experience (hmm, are those synonyms?), how to correct this tendency and to use composition and delegation to a greater degree. But now we have these wonderful new toys, and I think it will take a few years to get beyond its gleaning newness and to learn how not to abuse them.

    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.


      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....

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://346064]
Approved by matija
Front-paged by Courage
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (5)
As of 2022-12-07 14:36 GMT
Find Nodes?
    Voting Booth?

    No recent polls found