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]
pgpqAaLLYGQax.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel