Phil Longstaff <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]

Attachment: pgpqAaLLYGQax.pgp
Description: PGP signature

_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to