Object fields vs slots

[Josh Sled]

Phil Longstaff <plongstaff at rogers.com> writes:
> What is the rationale uses to decide whether to make an object attribute 
> a field in a structure vs a slot?  An Account has the hidden, 
> tax-related and placeholder attributes which are slots rather than 
> fields in the Account structure.  What is the reason for that decision?  
> I know slots are used to hold sx information.  Are they used extensively 
> elsewhere in the system?

Many: Layering. Convenience. Laziness.

Very practically, a plugin (e.g. Business) can't define fields on a Engine
layer object, for instance.  It must use the generic storage.

However, that a Transaction's Notes – a very clear first-order field – are in
a KVP frame is just bad design.

The SX use, imho, is a bit less clear.  The fact that a Transaction was
created from an SX is "just advisory", so it's less threatening that it's in
a KVP frame.  Still, it'd be nicer if Transactions had a more formal "source"
field, that could be used for this purpose, as well as import, &c.  This is
an argument primarily from laziness. :)

They're convenient because the KVP data is (un)marshalled from XML
generically; this is a bad excuse for its use, imho.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20071220/4a6863c6/attachment.bin