I don't agree fully. I kind of like that the create would be reused, and see few real problems with it. The biggest concern is what to do with old classes in existing modules that one would like to be possible to cast to. It is also of course good to be able to explicitly declare that you allow an object to be casted to.
If we do use a ``cast method (there must be a better name available) I agree it should work as you say. One win here is the possibility to return an already existing object, as you say, but that isn't really that closely linked to this issue. I think that the possibility to somehow return an already existing object from the create method should be considered. I have missed that on some occasions. It would if nothing else make the implementation of a singleton class easy.
/ Martin Nilsson (lambda)
Previous text:
2003-05-06 23:20: Subject: Re: Implicit class construction, _cast() and `=()
I think the cast lfun interface has to be expanded a bit as well. If we do (A)B then the cast method in B should get the program A as second argument, I think.
I agree.
Further, if B has no cast method, should some ``cast (or even create) in A be called? Example: (Gmp.mpz)5 would then result in Gmp.mpz(5).
I don't think it's a good idea to reuse the create lfun for that since that'd mean create() could be used in a situation the class author probably didn't expect. A right-cast operator lfun seems like a logical extension, though. The best would be if proper static functions are implemented so that
(A) b
is tried as the equivalent of
A.``cast (b)
and not
(tmp = A(), tmp->``cast (b), tmp)
That would allow ``cast to return an existing object.
/ Martin Stjernholm, Roxen IS