in reply to Re^5: Some thoughts on Moose Attributes
in thread Some thoughts on Moose Attributes

I agree it's unlikely.

'nuff said.

Who said anything about a method call?

In the context of "Decoupling representation from behavior at the class or metaclass layer " I don't see how a faster direct access mechanism achieves that "decoupling". But I'll accept that I may have misunderstood you.

What I have in mind is something as fast as a lexical lookup, which as an indexed lookup (and, of course, modulo pad depth and optimization) is (often) quicker than a hash lookup.

I once went quite a long way in developing a closure-based object mechanism. By instantiating a full set of closures for every object instance--kind of JS prototypical I think?--you do get direct lexical access to instance variables. With the obvious downsides.

Maybe a new storage specifier somewhat like, but essentially opposite to state (perhaps 'volatile' or less C-like, 'instance'), could be added to perl 5 that would essentially create a new stash (duplicated from the package stash) could come into being for each new instance? Just a random thought that crossed my conciousness.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re^6: Some thoughts on Moose Attributes

Replies are listed 'Best First'.
Re^7: Some thoughts on Moose Attributes
by chromatic (Archbishop) on May 02, 2011 at 03:35 UTC

    A new storage specifier might work, but the best way I've seen to implement this is to go all of the way to a full-fledged metaobject system. At the point where you can separate method dispatch from the normal global lookup system plus inheritance fallback, you allow for the possibility of type specialization and optimization, perhaps through a finalization system or (my preference) a tracing optimizer at runtime.

    From there you can get to autounboxing-style optimizations. (Remember that research into Self and Smalltalk and Strongtalk shows that 90% of all dynamic language programs are statically analyzable.)

      From there you can get to autounboxing-style optimizations. (Remember that research into Self and Smalltalk and Strongtalk shows that 90% of all dynamic language programs are statically analyzable.)

      I assume that this is more a nod to perl6/parrot than perl5.

      I do wonder about the effectiveness of a strategy of looking at runtime optimisations for languages like Perl. It makes sense for Java and Javascript--at least for download&run applications--because you cannot know the platform before runtime. But unless it is seriously envisioned that there will be a browser plug-in, it doesn't make as much sense for Perl.

      Perl 6 (Python, Ruby etc), would be better served by compile-to-native facility I think.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        I assume that this is more a nod to perl6/parrot than perl5.

        It's much more likely for the former than the latter. Nothing in the design of Perl 5 makes this impossible—most of the problem is that the internals of Perl 5 make it herculean.

        Perl 6 (Python, Ruby etc), would be better served by compile-to-native facility I think.

        You can only get so far with AOT compilation because you can't coalesce all variant types into a single possibility in most programs without evaluating them. That problem is worse in Perl 5 than in Perl 6, but it still holds true for any program where you have runtime manipulation of metaobjects (or byte code or parse trees or...) or dynamic loading. You can use a technique such as profile-driven optimization by running a typeful profiler against a comprehensive test suite, but even in that case you probably have to add guard conditions to your optimized code as a sop to uncertainty (if you trust your test suite that much).

        (I know you know this, but perhaps other readers do not.) eval and dlopen and AUTOLOAD and gradual typing mean that you don't always know enough about what's going on in any given code unit to optimize it fully until you actually execute it.