To: fessant@pa.dec.com
Subject: Re: Objects contrib: new URL ...
In-Reply-To: Your message of "Thu, 17 Jun 1999 10:16:32 -0700 (PDT)"
<14185.11632.214915.820706@virtualc5.pa.dec.com>
Message-Id: <19990618101902C.garrigue@kurims.kyoto-u.ac.jp>
Date: Fri, 18 Jun 1999 10:19:02 +0900
From: Jacques GARRIGUE <garrigue@kurims.kyoto-u.ac.jp>
From: Fabrice Le Fessant <fessant@pa.dec.com>
> In our case, the "cast" construct for the object-oriented programing
> style can be compared to the "ref" or the "array" types for the
> imperative programming style. Both can lead to "unsafe" programs
> (should the compiler allow "x.(-1)" in a program as it currently does?),
> but they can still be useful when used carefully. In that way, I trust
> Ocaml users (demagogy :)).
Agreed for array indices. Looks like a "needed evil" since the only
way to avoid it would be dependent types (still, some people work at
it).
I don't see what is the problem with refs? This is an impure
feature, but not dangerous in terms of type safety.
And of course there are also exceptions, which are pretty bad when
used the wrong way.
> With this patch, I tried to increase the expressiveness of the language,
> without breaking its safety. In this way, I think it is still better
> than using Obj.magic, since the "implements" checks whether the types
> can correctly be coerced.
I agree that this is better than Obj.magic. However it lets people
program in a JAVA-like style, quitting safe parametric polymorphism
(i.e. parametric classes) for unsafe dynamic type checking.
With your patch one can define collection classes without parameter,
put anything inside them, and downcast to get the contents, like one
does in JAVA.
The problem is that lots of people come to caml from a world where
casts are the standard way to obtain polymorphism. If you provide it
with an easy syntax, they will not bother to learn about the benefits
of parametric polymorphism (anti-demagogy :)).
So I weaken my statement: casts are not an absolute evil which should
not be allowed at all, but at least they should be hard to use, enough
to encourage people to choose other methods when possible.
> > Remark:
> > You can already implement something similar inside the language:
>
> Can you really use an object (mutable) as the key in the hashtbl (its
> hash value may change when it is modified ?) ?
Objects have a unique oid, which is used for comparisons and hashing.
Cf. byterun/hash.c.
I must admit that your approach is more efficient, since you just have
to check the pointer to the class. But again perfection may be a bad
thing for an unsafe feature...
Regards,
Jacques
P.S. Thanks for your path-to-the-patch.
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:23 MET