Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: On the Improvement of Exegesis 12

by BrowserUk (Patriarch)
on Apr 18, 2004 at 22:16 UTC ( #346163=note: print w/replies, xml ) Need Help??


in reply to On the Improvement of Exegesis 12

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

Replies are listed 'Best First'.
Re: Re: On the Improvement of Exegesis 12
by kelan (Deacon) on Apr 19, 2004 at 14:23 UTC

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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://346163]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (1)
As of 2022-11-28 02:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?