[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
UnaryFns & Tables
- To: <mark>
- Subject: UnaryFns & Tables
- From: Eric Dean Tribble <tribble>
- Date: Wed, 25 Oct 89 23:17:12 PDT
- Cc: <heh>, <xanatech>
- In-reply-to: <MarkS.Miller'smessageofWed>,26 PDT <8910260230.AA17372@xanadu>
and have exactly the same properties, so they should be the same 1) Don't use the word occlude. That has too many meanings in user
interface design. It also doesn't mean quite the right thing. If
nothing else, the occlusion is incidental. The primary result is
having a combined collection. What's wrong with combine?
Because it means something different than what we're already using
"combine" for in Orgls---reject the attempt if there's a conflict.
With tables, if there's a conflict, the receiver wins. If you think
we should redefine Orgl::combine to mean this too, then we should
consider using this term for Tables. Otherwise it just creates
confusion. Besides, "occlude" seems assymetrical, and "combine" seems
'Occlude' makes me itch. Here's some alternatives: combine, atop,
withAll, addAll, join, joinAll, compose, storeAll. My favorite is to
use the name of the operation for replacing or copying with one extra
key-value pair and adding 'All' to it. That would be 'storeAll',
'introduceAll', or 'replaceAll' for MuTables, and 'withAll' or some
such for ScruTables.
2) I don't want to unify Tables and UnaryFns. It corresponds to
keeping your mind so open your brains fall out. It's easy to
understand Tables. It's easy to understand UnaryFns. It's not easy
to understand count for a UnaryFn, or coordinateSpace, for that
matter. That makes both abstractions less useful. I've been quite
surprised and extremely annoyed when I invented an abstraction to
general and powerful for most of my problems.
The last comment was anecdotal, not directed at your suggestion.
Realize that coments get more direct as I type faster. Sorry.
I'm sympathetic to this. My problem is: is it always clear when I
want a given mapping to be a Table, and when I want it to be a
UnaryFn. If you can articulate a clear criteria I can use to decide
the cases I come across, that'll be interesting. Criteria like "this
feels like a function, but that feels like a table" are not
Here's a couple: 'Do I care about the count of the domain?' If so,
then a table is appropriate. 'Is it a map from Positions to Objects or
from Objects to Objects?' Remember that Tables only map from
Positions in a given CoordinateSpace (this is where CST come up
Here's a major difference that probably cannot be formalized: Tables
map from particular positions (a particular set of keys) into some
fixed set of objects. UnaryFns map from an infinite set of objects
that have some property into an infinite range of objects related to
the domain objects.
Finally, it's easy to describe the relation between UnaryFns and
BinaryFns. What's the relation between BinaryFns and Tables?
Can you think of any other differences in usage that derive from a
difference in desired protocol?
Sometimes forcing a conceptual unification of things that feel
different but have very similar formalisms creates power and
generality. Note the Scheme decision to unify the name spaces for
variables & functions, or to unify procedure calling and loops.
Names for functions and names for variables provide exactly the same
service. Therefore it's unrelated. They didn't unify procedure
calling and loops in scheme, they eliminated special loop constructus
because they could do loops with procedure calls. Again, unrelated.
Let's not continue this argument, though.
Recall Alan Kay's dictum: "Similar features should be made either
completely different, or the same".
I agree. Answering the above differences will be instructive one way
or the other. I suspect we'll want to make them completely different.
Note that this principle applies more to the description than to the
functionality. A well designed class might have one name with
associated semantics and usage. It could also masquerade under
another name with a different semantics and usage. If the semantics
and usages were sufficiently distinct and understandable, it wouldn't
break the above principle. (If I ever discover such a thing, I'll let
you know :-)
How did coordinateSpaces enter the picture?
As noted above for Tables.