The way this post reads to me is that MI is expensive in dynamic languages, and traits are one of many attempts to address that – that if MI were cheap, we wouldn’t need traits.

Then I failed dismally in my attempt to convey what I was trying to say :(

Yes, MI becomes rapidly unworkable in extended hierarchies.

Yes, Traits and it's kin are an attempt to reduce that complexity.

Yes, MI is expensive in dynamic langauges.

But definately NO to if MI were cheap, we wouldn’t need traits..

I did say (twice) that I am convinced that the basic issue that they are trying to address needs tackling.

What I hoped to point out is that there are many subtly different attempts at descriptions for solutions being proferred currently, but that they are concentrating on their differences--which are minutae relative to the problems of performance and footprint that they bring with them.

In compiled languages, where most of the groundwork for Traits and the others is being done, the complexities of method resolution and search order are compile time only costs. By runtime, the method call has been resolved either to a vtable entry, or to the actual entrypoint address.

Perl, (and all dynamic languages), already have a performance problem with method lookup. One of the major benefits that is hoped to come from the Parrot project is a reduction in the overheads associated with the mechanics of subroutine invokation--stack setup, scope maintenance, closure propagation, etc. If that effort succeeds, then it could reduce the costs of calling a sub to the point where static (compile time) MI would be tolorable from a performance point of view, though the inherent brain-melting problem of MI would persist.

It would also make Traits (and similar solutions) a practical solution to that MI complexity--but only if the method resolution can be fully resolved at compile-time

The fear I have is that Perl 6, and other dynamic languages that are trying to adopt trait-like behaviours, are also adding

  • Pre & post method entrypoints.
  • Dynamic inheritance resolution.
  • Dynamic vtables at the class (and maybe instance) level.
  • Full introspection.
  • Runtime macro capabilities.

    Each of these things adds runtime cost to the process of invoking a method.

    The code reads: 

    $obj->method();

    [download]

    The interpreter has to do

    1. Is method a macro? If so, expland it.
    2. What is the class of $obj?

      That's at least a two levels of indirection. One to look up the class name. One to look up the hash storing the method names associated with that classname.

    3. Can classX do method?

      If not, then look up the list of classes/traits/roles that it might inherit this method from.

      Also look up classX' search pattern (depth/breadth/etc.).

      For each superthing, lookup the address of it's vtable and check if it can do the method.

      If not, then look up the list if it's superthings and their search patterns, and vtables and see if they can supply the method.

      Keep going until you find it, or exhaust all possibilities and raise a non-existant method error.

      What happens if you find two (or more) superthingies that could provide that method? Now you have to go through a conflict arbitration process.

    4. Assuming that after all that, we isolated a resolution for the method, we now have to go through lookups for PRE() & POST() methods, and about half a dozen other SPECIAL subs that can be associated with a method or the class it is a part of.

    And that lot, even with the inherent loops I've tried to indicate, is far from a complete picture of the processes involved if all the features muted for P6 come to fruition. All of that was just to find the method to invoke.

    Now you have to sort out all the actual-to-formal parameter mappings, with all the

  • slurpy/non-slurp.
  • named/un-named.
  • required/optional.
  • read-only/read-write
  • by-reference/by value.
  • defaulted/no-default.
  • type constrained.
  • range constrained.
  • does constrained.
  • is constrained.
  • will constrained.

    possibilities and combinations thereof.

    And many of those will themselves require class hierarchy and method resolutions.

    Yes, I agree that there is a complexity problem with MI that must be addressed, but I also see huge performance problems arising out of the solutions be proposed, which when combined with all the other performance sapping, runtime costs being added through the desire for even greater introspection and dynamism.

    Combined, these mean that the single biggest issue I have with the current crop of dynamic language implemetations, performance--which Perl is currently the best of the bunch--is going to get worse in the next generation, not better.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    In reply to Re^3: Informal Poll: why aren't you using traits? by BrowserUk
    in thread Informal Poll: why aren't you using traits? by Ovid

    Title:
    Use:  <p> text here (a paragraph) </p>
    and:  <code> code here </code>
    to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.