Damian Conway <[EMAIL PROTECTED]> writes: > Piers Cawley wrote: > >> Bugger. I was hoping that Perl 6 was going to make a Pixie like Object >> database easier to write; looks like I'm wrong. One of the things >> Pixie does is to attach its control data by magic to the object itself >> (rather than any particular variable pointing to it). This lets us do >> all sorts of useful stuff without invading the object since we know >> that it will carry our metadata around it. Please, consider making >> <but> properties attach to the target of a pointer rather than to the >> pointer itself. > > Err....no. That's rather the whole point of C<but> properties [*]. > > However, if your class returns a reference to an object and that reference > has the appropriate value properties ascribed to it (i.e. stuck on the > *reference*), then any access through that reference (or through any > subsequent copy of it) will see those properties. > > So your magic Pixie would look something like" > > class Pixie { > > method new($class: %args) { > return $class.SUPER::new(%args) > but Magic('whatever'); > } > > # etc. > } > > [*] People, we just *have* to find better names for these things! > I'd suggest we henceforth call them "value" properties (for C<but>) > and "referent" properties (for C<is>).
Hmm... Here's Pixie's interface: my $pixie = Pixie.new.connect('dbi:foo:bar', $user, $pass); ... my $cookie = $pixie.insert($some_arbitrary_object); # Time passes, we forget everything but the value of $cookie my $pixie = Pixie.new.connect('dbi:foo:bar', $user, $pass); my $locked_object = $pixie.get_with_locking_strategy( $cookie, Strategy::ExclusiveLock.new ); When $locked_object is collected, Pixie unlocks it in the database. If, while $locked_object is in scope something else tries to fetch an object with the same cookie (from within the same thread) then Pixie hands 'em a reference to the same object. Right now Pixie keeps a handle on everything by attaching 'ObjectInfo' objects to every object that comes under its control so it can keep track of what's going on (it's a two way link, the object has a normal ref (via magic) to the objectinfo, which has a weakref back to the object itself, so when the object goes out of scope, the objectinfo goes out of scope too, triggering unlocking and other such stuff). So, if Pixie::get_with_locking_strategy looks something like: method get_with_locking_strategy( $self: $oid, Strategy $lock_strategy ) { return $self.cache_get($oid); CATCH Exception::NotInCache { my $flattened_object = $self.store.get_with_locking_strategy($oid, $lock_strategy); my $obj_info = ObjectInfo.new.set_pixie($self) .set_oid($oid) .set_lock_strategy($lock_strategy); my $real_obj = Storable::retrieve($flattened_object) but PixieInfo($obj_info); $obj_info.set_real_object($real_obj); $self.cache_insert($obj_info); return $real_obj; } } method cache_get( $oid ) { my $info = %.cache{$oid} // die Exception::NotInCache.new; return $info.real_object; } Will every copy of the value of $real_obj have the PixieInfo property? Am I going mad, or is order really that important? My initial idea was to do the C<set_real_object> and C<cache_insert> and then just do C<return $real_obj but PixieInfo($obj_info)>, but then, if I understand you correctly, the Info object's back reference to the real object wouldn't have a PixieInfo property, which would in turn mean that cache_get's return value wouldn't have the property and Bad Things would happen. It seems counterintuitive that the order of operations in this case should be so important. Or am I missing something? -- Piers