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