I was hoping to confirm that the record values really can't be used
directly as namespaces before I went into a big, long explanation of why
I don't like that. Then I realized that people might be more likely to
care if they knew the reason.
I know it's almost the deadline to vote, and this isn't going to
determine my vote by itself, but I'd like to hear what others think.
So here it is:
Say you want to create a container for values that have a "weight,"
which is just some nonnegative number. You want to limit the total
weight of everything in the container, but you don't want to limit the
values to a particular type, and you want to mix different types of
values in a container.
Without record types, you'd probably have a definition somewhere like:
(define (add value weight)
;something)
With 5.97 record types, it would be:
(define (add value weight-accessor)
;something)
That's almost exactly the same, which is a problem for me. Record types
are supposed package up multiple values in a single one for convenience.
If that packaging only covers passing around but not actually using the
fields, it's not very convenient.
That's a tiny example with one field, but records are supposed to help
you manage many fields. A serious record system should make it easy to
handle a case where you're accessing and mutating five fields and
passing the record to other procedures that work with other fields.
I'd like to see records handled like vectors, but with symbols instead
of numbers:
(record-ref record 'field)
(record-set! record 'field value)
You could hack together something like that using inspection, but you
shouldn't have to and it wouldn't work on opaque types.
There's also a related problem with inheritance. To know the name of a
default accessor or mutator (so you can import it) you need to know the
name of the type that it was defined in, which may be an ancestor of the
type you are using.
A typical use for inheritance is to create a library with a hierarchy of
types, export from the bottom inheritance tree, and use the higher nodes
for organization -- allowing the accompanying library functions to
easily handle several exported types by working higher in the tree. The
default accessor and mutator names would force the importer to know the
details of the internal bookkeeping types.
Of course, you can get around that by not using the default names, but
the default behavior should be suitable for the typical uses.
--
Brian Jaress
brian_jaress at gna.org
http://brian-jaress.livejournal.com
Received on Sun Aug 05 2007 - 17:20:06 UTC