Take for instance String.Buffer. It has a create function that takes the size as an integer, not a string as initial content. So the expression
(object(String.Buffer)) 17;
would not return a String.Buffer object representing the integer 17 in any reasonable sense. Therefore it'd only be a source of confusion to allow that syntax. There are many create functions like this one.
I think that the possibility to somehow return an already existing object from the create method should be considered.
Yes, it's a somewhat unrelated issue. If proper staticness is implemented then a sane extension is to allow create() to be declared properly static, in which case it would be expected to return the object to use.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-06 23:33: Subject: Re: Implicit class construction, _cast() and `=()
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)