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

Does the average class need to have complete freedom to separate instantiation representation from the class?

As an implementor, I answer wholeheartedly yes.

The naïve implementation of an object system in Perl 5 (stolen almost whole cloth from Python) actively presentsprevents many simple and nearly all clever optimizations. Decoupling representation from behavior at the class or metaclass layer would allow gradual and progressive optimizations for memory usage or compatibility with C data structures or persistence mechanisms or JIT with much less work (and much, much less cleverness) than doing so with the simple hash-based lookup mechanism currently in place in Perl 5.

In the Moose API, compatibility with existing classes is probably more of a concern.

  • Comment on Re^3: Some thoughts on Moose Attributes

Replies are listed 'Best First'.
Re^4: Some thoughts on Moose Attributes
by John M. Dlugosz (Monsignor) on May 02, 2011 at 02:19 UTC
    (stolen almost whole cloth from Python)
    Really? I had no idea!

      Apart from bless and references (the syntax of the object system) and, with modern versions of Python, a sort of metaclass system, they're effectively the same slot-based system. They even share some of the same flaws, such as the fact that importing functions into a namespace makes those functions accessible as methods.

Re^4: Some thoughts on Moose Attributes
by BrowserUk (Patriarch) on May 02, 2011 at 00:15 UTC
    As an implementor, I answer wholeheartedly yes. The naïve implementation of an object system in Perl 5 (stolen almost whole cloth from Python) actively presents many simple and nearly all clever optimizations. Decoupling representation from behavior at the class or metaclass layer would allow gradual and progressive optimizations for memory usage or compatibility with C data structures or persistence mechanisms or JIT with much less work (and much, much less cleverness) than doing so with the simple hash-based lookup mechanism currently in place in Perl 5.

    Sorry, but that is tantamount to the single most dishonest thing I've ever seen expressed on PerlMonks!

    I usually refrain from trying to predict the future, but: It ain't never gonna happen. Any of it.

    You don't need to implement the whole solution to prove me wrong. Just a single demonstration of method call being faster than a hash lookup in Perl 5.

    Implement the extension/optimisation in any language you like, but I bet you cannot return a previously set value, to perl via method call, quicker than it can be retrived from a hash.

    Note: I'd really like you to prove me wrong. Because such an optimisation could be very beneficial in almost every area of perl.


    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.
      It ain't never gonna happen.

      I agree it's unlikely.

      I bet you cannot return a previously set value, to perl via method call, quicker than it can be retrived from a hash.

      Who said anything about a method call? 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.

      With that said, optimizing method lookups where possible is also useful, and perhaps necessary in this case. I believe this is most feasible with a system of gradual optimizations. It's also highly unlikely with the Perl 5 source code as it is now.

        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.