> At 23:41 +0200 98/07/01, Frank Mittelbach wrote:
and up at 6 in the morning which is one reason why i'm not spelling
out everything, but it seems i would need to and probably more so.
> >essentially i said this already in my mail a few days ago but perhaps
> >it was not clear enough to people not having written large scale
> >low-level TeX.
> The reason I continued was that I got the impression that Frank
> Mittelbach misunderstood the whole idea of modules. :-)
but your impression is wrong
> >one of the main arguments for submodules (or class structures in OO
> >languages) is the ability to overload functions/procedures
> Not really. So called name overloading does not have anything to do with
sorry i probably shouldn't have used "main"
but don't you see that my arguments apply to your other advantages (to
a large extend) as well?
> The main idea with modules, the way I see it, apart from avoiding name
> clashes, is allowing the developer to develop in logical units without
> having to bother about the internals of other modules, only their
> interface. (So the question of writing out the names directly or by some
> parsing mechanism is a question of giving the module a different interface.)
> The question is how much of this that can be made in TeX, but this is
> another question.
no that is the question
> Summing it up, the use of names \foo_bar_baz:nn and viewing them as a
> part of a group named "foo" is already in some sense a module, where the
> use of "_" confuses the two concept of a module separator and a word
which is why the first word in the spec is called <module>. whether
using a spec like we did is confusing or not is a question of
perspective and if all you are interested in is having the module part
being separated by /es and not by _ then there is nothing really that
you would need to experiment other than looking about what you
consider reads better or does not confuses the issues --- and the
latter is mainly a question of personal feelings
so summing up
> (Roughly a translation of the concepts: 1. name-spaces/classes; 2. name
> overloading; 3. name-spaces/classes, 4. runtime derived OO classes; 5. code
> encapsulated in classes; 6. class derivation.)
other than 1 and 3 (which are basically provided already even though
you don't like reuse of _) none of the above is doable without runtime
lookup strategies not using the token based approach of TeX.
which i claim is deadly on the base level we are talking about.
again prove me wrong; as i said in my other message it is easy
enough to stay within the naming conventions of L3PL as of now and
extend them to allow submodules so this is no argument for my
challenge to prove me wrong by implementing anything of the above for
> Those objectives make sense, even though it can be hard to figure out how
> to do it in TeX.
i subscribe to the idea that those objectives make sense; it is not
that i never heard of them (being married happily to an OO-expert for
14 years) or applied them --- it's the "figure out how to do it in
TeX" i claim is the crux in the matter.
so please don't just advertise these objectives abstractly, that is
done enough and if you still think i misunderstand the whole idea
behind what you are saying please also think that i will do this
forever unless you show your ideas within a running tex system