[VOTE] generics: have methods returning objects infer the type from the receiving variable type (was: clarifying a generics issue)

[Marshall Schor <ms...@schor.com>]

I can see Adam's point.

If there was some way to do an explicit cast that worked for
collections, then I would be happy with that.

In other words, if we had something of type List<Number> and I knew the
list really contained only Integers, if there was a way to cast this:

  List<Integers> i_know_what_i_m_doing = .... ( 
(Magic_doesn't_really_exist_cast) something_returning_a_List<Number>))

then I would be happy.

It just seems to me to be too much to give up in the trade off - to lose
the ability to have a List<Integers> when I know that's what I have.
 
That's the point I'm trying to make. 

One way around this, for instance of CASImpl and CAS etc., is to have
alternative forms of the affected methods, such as
   Iterator<CAS> getViewIterator()   // the public, normal one, and
   Iterator<CASImpl> getInternalViewIterator()  // one that might be
"public" but not part of the public API

The bad/sad part of this is this violates the write-it-once philosophy
:-( ...

Of course, now that we have Java5 as a base, and given that
getViewIterator actually constructs a real list object, and returns an
iterator over it, it would make more sense in this case to have an
"internal" method that returned the List, which implements Iterable,
which would make it work in for-each loops :-)

So - can we close up this discussion with a vote on the following:

On the normal scale of -1, 0, +1, to the proposition -

have the generic form of many methods that are in the public API for
UIMA that return UIMA objects, return a type which is inferred from the
receiving typed variable,  versus having it return just one fixed type
not inferred from the receiving typed variable,

Marshall:  + .5   (somewhat in favor, but can live with not doing
inference, perhaps implementing "internal" versions)


Adam Lally wrote:
> On Tue, Aug 11, 2009 at 10:44 AM, Jörn Kottmann<ko...@gmail.com> wrote:
>   
>> Adam Lally wrote:
>>     
>> Lets say we have an interface Box{Number getNumber()}
>> then we could have a class BoxImpl implements Box{Integer getNumber(){...}}.
>>
>> Now I only would have to cast once
>> Box box = ...;
>> BoxImpl boxImpl = (BoxImpl) box;
>>
>> now
>> Integer number = boxImpl.getNumber()
>> would work. Sure if you do the same for CAS and CASImpl
>> you safe lots of casts.
>>
>> The same does not work for a getNumbers which
>> returns a List<Number> or Iterator<Number>
>> without also allowing down casting.
>>
>>     
>
> Well, true, but it does not really create an analogous solution if you do:
> interface Box{List<T extends Number> getNumberList()}
> class BoxImpl{List<Integer> numberList()}
>
> Because a client could call
> List<Integer> x = box.getNumberList()
>
> whether or not box was actually a BoxImpl.
>
>  -Adam
>
>
>   

Re: [VOTE] generics: have methods returning objects infer the type from the receiving variable type

[Jörn Kottmann <ko...@gmail.com>]

Marshall Schor wrote:
> On the normal scale of -1, 0, +1, to the proposition -
>
> have the generic form of many methods that are in the public API for
> UIMA that return UIMA objects, return a type which is inferred from the
> receiving typed variable,  versus having it return just one fixed type
> not inferred from the receiving typed variable,
>
> Marshall:  + .5   (somewhat in favor, but can live with not doing
> inference, perhaps implementing "internal" versions)
>
>   
-1, but there are a very few methods where type inferring
from the receiving typed variable would improve the calling
code.

Jörn

Re: [VOTE] generics: have methods returning objects infer the type from the receiving variable type (was: clarifying a generics issue)

[Adam Lally <al...@alum.rpi.edu>]

On Tue, Aug 11, 2009 at 3:16 PM, Marshall Schor<ms...@schor.com> wrote:
><snip/>
> So - can we close up this discussion with a vote on the following:
>
> On the normal scale of -1, 0, +1, to the proposition -
>
> have the generic form of many methods that are in the public API for
> UIMA that return UIMA objects, return a type which is inferred from the
> receiving typed variable,  versus having it return just one fixed type
> not inferred from the receiving typed variable,
>

-1

Adam

Re: [VOTE] generics: have methods returning objects infer the type from the receiving variable type

[Thilo Goetz <tw...@gmx.de>]

Marshall Schor wrote:
> I can see Adam's point.
> 
> If there was some way to do an explicit cast that worked for
> collections, then I would be happy with that.
> 
> In other words, if we had something of type List<Number> and I knew the
> list really contained only Integers, if there was a way to cast this:
> 
>   List<Integers> i_know_what_i_m_doing = .... ( 
> (Magic_doesn't_really_exist_cast) something_returning_a_List<Number>))
> 
> then I would be happy.
> 
> It just seems to me to be too much to give up in the trade off - to lose
> the ability to have a List<Integers> when I know that's what I have.
>  
> That's the point I'm trying to make. 
> 
> One way around this, for instance of CASImpl and CAS etc., is to have
> alternative forms of the affected methods, such as
>    Iterator<CAS> getViewIterator()   // the public, normal one, and
>    Iterator<CASImpl> getInternalViewIterator()  // one that might be
> "public" but not part of the public API
> 
> The bad/sad part of this is this violates the write-it-once philosophy
> :-( ...
> 
> Of course, now that we have Java5 as a base, and given that
> getViewIterator actually constructs a real list object, and returns an
> iterator over it, it would make more sense in this case to have an
> "internal" method that returned the List, which implements Iterable,
> which would make it work in for-each loops :-)
> 
> So - can we close up this discussion with a vote on the following:
> 
> On the normal scale of -1, 0, +1, to the proposition -
> 
> have the generic form of many methods that are in the public API for
> UIMA that return UIMA objects, return a type which is inferred from the
> receiving typed variable,  versus having it return just one fixed type
> not inferred from the receiving typed variable,
> 
> Marshall:  + .5   (somewhat in favor, but can live with not doing
> inference, perhaps implementing "internal" versions)

-1

--Thilo