object properties

Hello everyone.

I've noticed that Dolphin allows any object to have properties. For what I
understood by inspecting them, this properties are weak, that is, they are
not part of the object (when stbout filing it, for instance), and will go
away when the owner object is garbage collected.
I saw the package manager uses this properties to mark a package as changed,
and that the drag & drop framework uses them to keep track of the target of
a drop list. My question is: do this properties have a well known semantincs
in Dolphin ? I mean, besides this 2 examples, what have you used them for ?

For instance, will you say it's correct to use them to store an object id in
a very simple mapping to a relational database, or will it be doing a
"smart" thing with something meant for other purposes ?

Thanks in advance.
Martin

Martin wrote:

> I saw the package manager uses this properties to mark a package as
> changed, and that the drag & drop framework uses them to keep track of
> the target of a drop list. My question is: do this properties have a well
> known semantincs in Dolphin ? I mean, besides this 2 examples, what have
> you used them for ?

I tend to use them for fairly ad-hoc purposes.  For instance my Packages
"know" what external files they need (icons, and so on) so that when I rebuild
the data for my website, the relevant files get included in the ZIPs.  That
data is held as "properties" of the package (and is actually set by the
packages' own post-install scripts), which means that each package can hold
that data itself rather than being dependent on any other package (except the
Dolphin base).

In general, though, I wouldn't use the properties system for more structured
information.  If you know that some object needs to hold some data about some
other objects, then it is easier to make that object hold it itself (maybe
using a weak collection of some sort).  If you use the properties system then
each access to a datum is via a double lookup, first find the object in a
global weak dictionary, then find the named data-item in a second level
dictionary.  If you held that data yourself then there'd only be one lookup.
Of course the difference in performance is probably not going to be
significant, but when a solution is both cleaner /and/ faster then I tend to
prefer it ;-)


> For instance, will you say it's correct to use them to store an object id
> in a very simple mapping to a relational database, or will it be doing a
> "smart" thing with something meant for other purposes ?

It would certainly be an easy way to get that part of the system prototyped and
more-or-less working, but I think that in the end you'll probably have (say)
Object>>oid and Object>>oid: methods (or maybe something very different, but
there'd still be /some/ API that hid the details), and then it's just an
implementation question whether #oid reads:

    oid
        ^ self propertyAt: #MartinStuffOID ifAbsent: [nil].

or:

    oid
        ^ MartinsDB current oidFor: self.

if you see what I mean.

    -- chris