Object fields vs slots
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? Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Object fields vs slots
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
Re: Object fields vs slots
Josh Sled [EMAIL PROTECTED] writes: 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. Also historical and datafile compatibility. All KVP info is fully backwards and forwards compatible whereas structure information is not backwards compatible. Very practically, a plugin (e.g. Business) can't define fields on a Engine layer object, for instance. It must use the generic storage. True. However, that a Transaction's Notes – a very clear first-order field – are in a KVP frame is just bad design. Yes and no. It means that you could go backwards to a version of gnucash before that field was added, load the data file, make changes, save the data file, and then go back forward again and your Notes field would still be there. If, however, the Notes were added as a first-class field, then going backwards and forwards would either: a) fail to load in the older version or, b) lose the notes data in the back-and-forth transition. Granted, this is all due to the fact that gnucash doesn't store the DOM tree. Instead it has hand-written parsers and then throws away the DOM tree and recreates it at save time, losing anything in the DOM tree tha the parsers don't understand. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
