Hi Thorsten,

> a very nice feature of the PicoLisp object system is the ability to add
> new attributes at runtime (add new properties to the symbols property
> list), e.g. create an object with 5 attributes although the class only
> expects 2 attributes.


> But what about external symbols (entities)?
> ...
> ,------------------------
> | (class +Client +Entity)
> | (rel nm (+String))
> | (rel tel (+Number))
> `------------------------
> and I want to create a new object of this class - preferably by assigning
> a whole well-formed property list to a symbol with 'putl' or so, without
> using 'new' (if that makes sense)

This is not a good idea in general. The reason is that the '+Entity'
classes build a layer above the plain symbol properties.

Therefore, a property of an '+Entity' should always be assigned using
'put>' and related methods. These methods take care of maintaining all
side effects necessary for DB consistency.

In the above case, a plain 'put' would work accidentally, because the
'nm and 'tel' relations do not define any indexes or other dependencies.
They are just atomic '+String' and '+Number' properties. But if you had
e.g. (+Key +String) or (+Ref +Number), simply 'put'ting a value would
bypass the maintenance of these indexes.

Instead of using 'putl', you could simply map over the list with 'put>'.

> - how is this relation info stored in the property list? 

The property lists of external symbols are just like for internal or
transient symbols.

But for Entities, this "relation info" is maintained in other objects
(e.g. for '+Joints') or other external symbols (e.g. the nodes of index

> - and how can I specify that an additional property like e.g.
>   (01731234567 . mobil), given at runtime, is a relation of class
>   +Number?

You could store non-relational information any time in an external
object with a normal 'put' (followed by 'commit'), as long it doesn't
involve any entity/relation structures. A plain number like the above is
no problem.

However, I would recommend always to use 'put>', because it avoids
confusion, and gives less trouble in case where e.g. an index is later
added to the relation.

♪♫ Alex
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to