> >
> > I fear that your share proposal will not interact well with separate compiling of
> > modules:
> > how can the list of all share definition be completely know to the compiler ?
It is not the case if you consider that two modules sharing the same
symbol
should declare it with the same type and then you merge the list of
possible values. Some value may be hiden by other, but this is already
the case for usual module field.
> Well, I can't remember offhand how SMJ/NJ handles overloading, but it
> seems to work reasonably well. On the other hand, I am nowadays a
> convert to ocaml's hard line on overloading---it's an absolute curse
> of many, many C++ programs by coders whose enthusiasm outruns their
> judgement.
I agree with you that one should not abuse overloading. The problem of
C++
is that you can even overload operator such as = ! I would live happy if
there was a finite, fixed and short lists of overloadable operator (In
fact arithmetic operators are the most needed).
The pb is that if you use twice the same functors declaring + (which is
unavoidable if you do formal calculus). You can never have access to
both symbols with their short names. So sharing/overloading
is really needed as soon as you use and reuse functors in complex ways.
-- Christophe Raffalli Université de Savoie Batiment Le Chablais, bureau 21 73376 Le Bourget-du-Lac Cedextél: (33) 4 79 75 81 03 fax: (33) 4 79 75 87 42 mail: Christophe.Raffalli@univ-savoie.fr www: http://www.lama.univ-savoie.fr/~RAFFALLI
This archive was generated by hypermail 2b29 : Thu Apr 20 2000 - 09:56:23 MET DST