[rucksack-devel] Some other things

[Levente Mészáros]

On 1/15/07, Arthur Lemmens <alemmens at xs4all.nl> wrote:
> > planned to support weak references?
>
> I'm not sure what that would mean in the context of Rucksack.  Could
> you explain what this would mean and why you would want them?

I thought it could mean the same thing it means for in memory objects.
Objects referred only by weak references will be garbage collected and
the weak references will be set to nil. For example one can have an
instance list for a particular class. This allows fast iteration over
instances and weakness means the object will not be kept unless it is
refererred by some other objects too. I think there are more
complicated examples where weak references help building efficient
application specific index structures without disturbing when objects
are garbage collected.

> > I implemented the serialization of structures using SBCL, this was
> > fairly trivial dispatching on structure-object. I did not look at
> > other implementations but will you include such patches?

> I'd like Rucksack files to be portable between CL implementations, so
> you can create a rucksack with one implementation and load it with another
> implementation later.  I'd also like Rucksack files to be self-describing,
> so that it's possible to recreate all persistent data even if you don't
> have the source of the program that created the data.
These are nice goals I think but I still think being able to serialize
structures is almost a must. There are libraries out there using
structures and one does not want to rewrite those to use classes so
that data can be serialized. So one either does not use rucksack or
patches it. To mention one such library there is local-time which uses
a structure to store the date/time and I guess it will not change in
the near future so comparing the structure definitions is not that
important in this case.

I think If structures cannot fullfill the above goals it's still
better to document it and let the user decide what to do than not
having structures at all.

> But if you can implement this in SBCL and can show that it will be possible
> to implement in a few other implementations, I'll gladly add it to Rucksack.

Probably it's doable in a platform specific way but to make this work
on several platforms is too much for me to do.

> > I also noticed that some slots (rucksack/transaction/etc.) of
> > persistent classes are persistent-effective-slot-definitions even
> > though they should not be. I guess this can be fixed in
> > direct-slot-definition-class and effective-slot-definition-class by
> > checking on the persistence flag.
>
> I don't really understand what you mean.  Could you be more specific?

RS-TEST> (sb-pcl::class-slots (find-class 'p-test))
(#<RUCKSACK::PERSISTENT-EFFECTIVE-SLOT-DEFINITION OBJECT-ID>
 #<RUCKSACK::PERSISTENT-EFFECTIVE-SLOT-DEFINITION TRANSACTION-ID>
 #<RUCKSACK::PERSISTENT-EFFECTIVE-SLOT-DEFINITION RUCKSACK>)

These should not be persistent slots but standard slots and the
standard svuc is sufficient for them. It mighe even be faster. I think
I'm going to give a try to send a patch of this.

> > I tried to implement a persistent base class called audited-object
> > which stores the time of creation, the time of last modification, last
> > modifier, etc. In principle an :after method on (setf
> > slot-value-using-class) could make it, but unfortunately I could not
> > distinguish between code setting the persistent slot outside of
> > rucksack and code internal to rucksack itself. Maybe rucksack could
> > use a function slot-value-using-class-internal which would bind a
> > special variable so that overriding svuc will be able to distinguish
> > between loading the object from the disk and setting a slot value by
> > the user.
>
> Yes, interesting idea.  I'd be inclined to create a new metaclass,
> say AUDITED-PERSISTENT-CLASS which inherits from PERSISTENT-CLASS, and
> define a new SETF SLOT-VALUE-USING-CLASS method for classes of that
> metaclass.  Your new method could then do tricks with special variables
> (if that's really necessary).

I think this is certainly not a meta-class feature it's doable much
simpler than that.

(defentity audited-object ()
  ((created-at
    (now)
    :type local-time)
   (last-modified-at
    :type local-time)))

(defmethod (setf slot-value-using-class) :after (new-value
                                                 (class persistent-class)
                                                 (object audited-object)
                                                 (slot
persistent-effective-slot-definition))
  (let ((slot-name (slot-definition-name slot)))
    (unless (or (eq 'created-at slot-name)
                (eq 'last-modified-at slot-name))
      (setf (last-modified-at-of object) (now)))))

The only problem is when setf svuc called I cannot decide whether it
is called by user code or rucksack itself. I think I'm going to try to
make a patch for this one too.

> You mean you don't like the extra pair of parentheses after
> WITH-TRANSACTION? Like
>
>   (with-transaction ()
>     (foo)
>     (bar))
>
> I love that empty pair of parentheses.  They give me a feeling of
> closure...

Fine, it's not that important and I can always have my own version. I
just though writing the () 99 percent of the time is really
superfluous. Well that's what LISP really is, you know the famous Lots
of ... ;-)

Something similar is when calling add-rucksack-root, rucksack-roots,
etc. those functions require to pass in a rucksack. Which is fine for
at least two reasons: because they need one and they want to dispatch
on it. On the other hand 99 percent of the time I guess this will be
*rucksack* which could be the default. I know that it is not doable in
a generic method if you want to dispatch on it, so it's a naming issue
again. How do we call those functions? I could only come up again with
the add-rucksack-root and add-rucksack-root* which I doubt you are
going to like too much.

Cheers,
levy

-- 
There's no perfectoin