RE: Structures comments

>Really terrific comments.

Thanks!

>(a) "export" is a natural counterpart to "import"

This is true in the sense that importing is getting something from
somewhere and exporting is sending something somewhere, but my point was
that the Structures document doesn't use export that way.

>(b) "export" has been used for more or less the same purpose 
>in describing other languages such as Modula-3 (and Pascal)...

That's good enough for me. Like I said about other "technical" usages, a
solid precedent is a good justification.

>I think I was careful to use the word 'export' as a verb

"Export" is fine as a noun (bourbon is a popular export of Kentucky) or
as an adjective (export tariffs). 

>My personal preference would be to export nothing by 
>default, as it forces one to be explicit about interdependencies. 

I had thought about this, but didn't say anything because we want to let
people create specialized versions of structures they didn't have a hand
in creating. We can only push the Java/C++ analogies so far here,
because the concept of an interface does not go along with information
hiding in the XML case--you can't use something unless you have access
to all the "source" code, so you can't say "here's the parts of my
archetype that you can change, don't worry about the other parts" as you
can when you distribute a binary class file and its documentation. So,
if I design something that happens to almost suit the needs of someone
I've never met who can get it off of my Web site, he or she should have
the option of refining it in addition to copying and editing it.

Bob DuCharme          www.snee.com/bob           <bob@  
snee.com>  "The elements be kind to thee, and make thy
spirits all of comfort!" Anthony and Cleopatra, III ii

Received on Tuesday, 18 May 1999 08:36:26 UTC