Stevan Little wrote:
This is extended into the other sigil types;
has %.foo;
is sugar for this:
has Hash $foo; # or has %foo, but really, the point is it's
# an implementation detail, right?
method foo is rw {
return Proxy.new( :FETCH{ $foo }, # or a facade
:STORE -> Hash $x { $foo = $x },
)
but {
method post_circumfix:<{}>($key) is rw {
return Proxy.new( :FETCH{ $foo{$key} },
:STORE -> $x { $foo{$key} = $x },
);
}
};
}
I am not sure if it makes sense to handle whats inside the hash with the
accessor. I think that is the responsibility of either the hash
container type itself, or what you really need here is some kind of
object to wrap your hash and get such fine grained control. But that is
just my gut reaction.
This is what the monkey-but syntax is about. The returned Proxy object
must behave like a Hash for the property to behave like a hash, which
(minimally) means implementing the post_circumfix:<{}>($key) method.
Quite what that looks like in the metamodel is another question; the above
makes it look like monkey-but can make anonymous sub-classes that derive
new methods, which I inducted as being potentially legal syntax from the
examples of monkey-but I've seen so far. Ideally this wouldn't have to
happen every time the attribute is accessed ;).
So, if you want a "visitor pattern", you grab a visitor iterator
via the Meta-Objects, right? Which could also solve the
STORABLE_freeze/STORABLE_thaw / Pixie::Complicity / etc problem by
unifying the way that "foreign" objects can marshall themselves to
Perl objects when required.
You mean for persistence operations? Where you need to thoroughly
inspect the object to save it to disk/DB/etc.
Yes, that sort of thing. Sending objects between processes in some
marshalled format, like YAML, XML, binary/Storable, etc. But there
are plenty of other applications of the visitor pattern; I think a
nice tidy split would be to either allow walking at the public attribute
or the private attribute level.
In the face of AUTOMETH, the public "attibutes" of a Class might not be
trivial to find, or indeed be infinite. So the class needs to have a way
to tell the visitor iterator which public attributes are considered to
represent the entire state of the object.
Of course, the same problem doesn't apply for visiting private attributes,
which are either there or not. I can see arguments for walking at both
levels for certain tasks.
I think the ideal way to write something like that would be to write is
as a metaobject. Meaning using the Persistent metaclass. As opposed to
using something on the "user" side of things to interogate the "meta"
side of things. But this may be because I am too deep into the meta side
if things right now.
Yes, I imagine that the iterator will be returned from a metaobject
method, with gratuitous use of callbacks to make the simple uses really
simple; including the logical equivalent of $File::Find::prune = 1.
Sam.
ps. Monkey-but Monkey-but Monkey-but
