Re: Re: Example Issue with Scala API Documentation and Scala Complexity

agreed

On Wed, Nov 30, 2011 at 9:22 AM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
> I'd go with ResultType. Yes, it is a bit redundant in that the
> namespace for it *is* the type namespace, but I think it makes reading
> it easier.
>
> On Wed, Nov 30, 2011 at 13:45, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
>> I would go with something shorter than ResultCollection; the signatures are
>> long enough already to be hard to parse.  "Result" at most, I'd say.
>>
>>   --Rex
>>
>> On Wed, Nov 30, 2011 at 10:38 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>
>> wrote:
>>>
>>> "That" is used an awful lot in the collection library, and I agree that
>>> better name (like ResultCollection) could be used.  It also helps understand
>>> CanBuildFrom ->
>>> CanBuildFrom[List[A], B, ResultCollection] // OH, right, building from
>>> List to some other collection, not sure about B yet...
>>> - Josh
>>>
>>> On Wed, Nov 30, 2011 at 10:33 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
>>>>
>>>> Related to the API documentation discussion--Ittay just pointed out a
>>>> confusing-looking method signature:
>>>>
>>>> def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf:
>>>> CanBuildFrom[List[A], B, That]) : That
>>>>
>>>> Although he was focused on a different aspect, I noticed a potential
>>>> problem with this one. Is there any chance that we can avoid having both a
>>>> "That" type and a "that" argument of a completely different type?  This is a
>>>> source change, not a documentation change, but it might make the method
>>>> signature less impenetrable.
>>>>
>>>>   --Rex
>>>>
>>>> P.S. Sorry--don't have time to make the changes myself, just point out
>>>> the issue.
>>>>
>>>
>>
>>
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>