Object fields vs slots

[Derek Atkins]

Josh Sled <jsled at asynchronous.org> writes:

> 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.

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
       warlord at MIT.EDU                        PGP key available