[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Inclusion Lists for Hypercardus Clonus
- To: <rick>
- Subject: Inclusion Lists for Hypercardus Clonus
- From: Marc Stiegler <marcs>
- Date: Tue, 13 Feb 90 09:58:00 PST
- Cc: <xtech>
A while ago, rick put out a message stoutly defending his ability
to implement Hypercardus Clonus with just text and inclusion
You're quite right, rick. You CAN implement good ole
Clonus that way. The only question is costs versus benefits.
The best news in doing Clonus with just inclusion lists and text
passages is that you don't have to learn much about Xanadu. This
is probably compelling for the first-time developer; whether
it is compelling for others depends on more factors. One of those
factors which I will address another day is the quality of the
documentation, the amount of assistance we can give developers
as they scrabble up the slope to the pinnacle of Xanadu expertise.
Another benefit of an inclusion list/passage based Clonus is
that you can kinda look at the CloneCards with any other frontend
that can read inclusion lists and passages, such as the infoFactory.
But this second benefit is actually more of a cost: you can kinda
look at the CloneCards with other things that really won't understand
them. My suspicion is that, for the ordinary user on an ordinary
day, we didn't do him any favors, letting him pick up a field&button
doc as an inclusion list.
If this IS doing him a favor, great, implement it this way. I
can imagine using the InfoFactory as a CloneCard editor--but
it would be a very raw editor, i.e., no syntax or semantic support,
the kind of thing Unix people would love, but which would be
suicidal for occasional users.
Anyway, if you agree that it's not wonderful to look at CloneCards
with the InfoFactory, then you probably want to give it a different
work type even if the structure remains the same.
And if you're going to give it a new work type, you might as
well ask, are there any ways I could build Clonus in Xanadu that
would make it faster, or more compact, or easier to understand
and maintain? As a simple example, the Card class document has,
as the first 2 entries in its inclusion list, the background
graphic and the background field&button document. Since those
2 fields always show up there, would it make more sense to put
them in pigeonholes in the work's main unordered orgl? This would
be slightly easier to understand for the new programmer, because
it maps the structure onto the purpose more clearly.
Ravi has other, stronger examples of things you can do with Xanadu
that would make Clonus easier and/or better, for the developer
who got more deeply into Xanadu objects. I'd be quite interested
to know if you consider the merits of using deeper Xanadu features
good enough to pay for the extra learning required.
So if you don't mind, I'll put a meeting on my meeting list
for you (rick) and ravi to discuss those items.