Re: [OT] Just a thought...
Re: [OT] Just a thought...
- Subject: Re: [OT] Just a thought...
- From: Q <email@hidden>
- Date: Tue, 4 Mar 2008 13:38:05 +1000
On 04/03/2008, at 1:17 AM, Florijan Stamenkovic wrote:
Hi all,
Would it not be cool if Java supported streamlined class conversion?
Something like this could be declared in the Object class, to be
overridden in subclasses:
public Class[] convertableTo(){ return new Class[0]}
public <T> T convertTo(Class<T> clazz) throws
CanNotConvertException { return null; }
This could then be used by the compiler, to determine convertibility
(well, as best as possible) at compile time... We could write stuff
like:
byte[] data = getSomeNSDataObject();
for(int i = 0 ; i < someArray ; i++) // here an array converts to an
int according to it's size
try{
int userInput = getUserInputString();
}catch(CanNotConvertException ec){...}
And this would be cool because then conversions (which we all do a
lot in our code) could be written implicitly, without the need to
call API specific methods like:
I think you can do this to a limited degree with Groovy by creating a
custom metaclass delegate for your target classes, but it's not
simple, and it's still advisable to do the conversion explicitly as
combining inheritance and type inference can result in valid but
unanticipated results. The biggest problem with this technique is the
cost of looking up the convertibility of classes at runtime. For
something like this to be efficient in a strictly typed language the
type conversion needs to be determinate at compile time.
This sort of behaviour could have been handled much more simply in
java if return types were used as part of the method signature at the
language level, rather than limiting methods a single signature with
inherited covariant return types.
That way you could define both:
public byte[] getSomeNSDataObject();
and
public NSData getSomeNSDataObject();
which is perfectly valid to the JVM, but not to the Java Language.
The compiler could then use type inference and the specificity of the
return type to choose the most appropriate method to call.
Additionally if the java language had also dictated that a pre defined
method such as "value()" be used to perform type variance, in the same
way toString() converts to a string, you could then define
public NSData getSomeNSDataObject();
and NSData would define
public byte[] value();
the compiler could then be made to interpret
public byte[] getSomeNSDataObject();
as
public byte[] (byte[])((NSData)getSomeNSDataObject()).value();
byte[] data = getSomeNSDataObject().bytes();
Well, I am sure there would be drawbacks to the implementation, or
better to say peculiarities :) , like with autoboxing and, ahem,
generics, but I can't think of any major problems, of the top of my
head... Well, there'd be more possibilities for screw ups, but Java
is generally easy going (compared to the C family at least), so a
bit more care would not kill anyone.
Yes, I am sure that if Java had supported this ability there would be
reasons to wish that it didn't.
--
Seeya...Q
Quinton Dolan - email@hidden
Gold Coast, QLD, Australia (GMT+10)
Ph: +61 419 729 806
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden