Re^5: Some thoughts on Moose Attributes

[chromatic]

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.

[BrowserUk]

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.

[chromatic]

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

[BrowserUk]

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.