At 13:55 +0100 97/10/14, Robin Fairbairns wrote:
>Hans Aberg writes:
>>   The correct way to understand if various object oriented techniques and
>> such are the right things, is to make a research prototype and then
>> experiment with that: Such techniques are otherwise difficult to
>> understand.
>
>What I said was, that Hans's proposal was interesting but that I
>hadn't concluded that it was the `right way forward'.  I meant exactly
>what I said: I didn't mean I didn't understand it.
...
>There is a
>problem with knowing whether it's necessary.  I believe it imposes an
>extra burden of understanding on the user (and hence of documentation
>on the implementor), so I don't want to rush into its use without
>being entirely sure that it's the right thing.

  Here we have the two OOP opposites at once: Even though it is not
difficult to understand the logical implementation structure once it is
done, it is still difficult to understand how to apply it, and figure out
if it is useful. Then, the reason for this is that one is implementing
structures from the real world which are not really needed for carrying out
the computations, but is a way to organize the programming.

>There is no problem in my mind with implementing Hans's suggestion
>(though I would be interested to see his implementation).

  I do not know how to implement true OOP techniques in TeX (in view of
those structural problems above). So it is great somebody else knows it. :-)

> If we are likely to run out of name space, Hans's proposal
>(which I would identify with
>
>  @InCollection{saltzer:names,
>  author =       "Saltzer, J. H.",
>  title =        "Naming and {B}inding of
>{O}bjects\nocite{bayer:os-advanced}",
>  crossref =     "bayer:os-advanced",
>  chapter =      "3.A",
>  pages =                "100--208"
>  }

>which is the classic naming paper) comes into its own.

  It's more than that, because in OOP, one could define "author" as a
structure containing several substructures, such as "name". Then the
structure "name", if it should be truly international could be highly
complex, with substructures such as "given name", "family name", "nick
name". When calling those substructures, one would normally not do it
directly, but through method calls corresponding to name formats
   Albert Einstein
   Einstein, Albert
and so on. The advantage is that the team making use of the "author"
structure need not knowing the details of what the team designing the
"name" structure is doing: So it is an advantage when the code evolves and
becomes rich on structure.

  Hans Aberg
                  * Email: Hans Aberg <mailto:[log in to unmask]>
                  * AMS member listing: <http://www.ams.org/cml/>