That would be structural, but I wouldn't allow it. The union type in a
manifest typed system should allow only calls to methods declared on
common supertypes of all types in the union. In your example that seems
to be Object.
To pick Reinier's example: if you get something that's either a gun or a
camera, then you'll have to figure out which one it is first.
In most cases I would expect an anonymous union to be used in a switch
statement or similar construct. You could have cases where one of the
common supertypes is sufficient, things like Number or Exception come to
mind. But in the bigger picture I'd expect that to be a less common case.
Peter
Ben Schulz wrote:
> That's what I was refering to as having to check the runtime type. I
> don't feel like you gained much in your sample, you could just replace
> "String | Integer" with Object and add a "default: throw new
> AssertionError();". Obviously you gained type safety, but it would be
> much more useful if unions were structural:
>
> public static void closeSilently(InputStream|OutputStream|Reader|
> Writer|Channel preCloseable) {
> try {
> preCloseable.close();
> } catch(IOException e) {}
> }
>
> With kind regards
> Ben
>
> On 19 Aug., 15:57, James Iry <[email protected]> wrote:
>
>> I don't follow. Union types don't seem particularly structural to me.
>> They're the disjunction of other types, and if the other types are
>> nominative then so is the union of them. A type like String | Integer
>> contians all expressions that are Strings or Integers. The idea would be
>> that you can write the followig. Here I'm borrowing a touch of Scala syntax
>> to allow switch on runtime type and use | to indicate disjunction of types.
>>
>> void foo(String | Integer argument) {
>> switch(argument) {
>> case s : String => "It was a String " + s
>> break;
>> case i : Integer => "It was an Integer " + i
>> }
>>
>> }
>>
>> The types of actual arguments would be checked statically. The type system
>> would allow foo("hello") and foo(42) but would not allow foo(false). For
>> backward compatibility, the argumenttype could be erased to the least upper
>> bound (in this case Object) in the bytecode.
>>
>> Similarly, you could write
>>
>> String | Integer foo(Boolean flag) {
>> if (flag) return 42;
>> else return "hello";
>>
>> }
>> On Wed, Aug 19, 2009 at 4:21 AM, Ben Schulz <[email protected]> wrote:
>>
>>
>>> I'm not much of a PLTist, but I'm guessing the reason uions don't make
>>> it into general purpose, object oriented languages is that they're
>>> inherently structural. Just a guess though. (The alternative is having
>>> to check the runtime type and downcast, which pretty much defeats the
>>> purpose.)
>>>
>>> With kind regards
>>> Ben
>>>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
