method return-typing (was Re: Date&Time api)

Ben Coman wrote

> On Tue, Aug 18, 2015 at 1:21 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>
>> Hi,
>>
>> there are some weird things around the data & time API. So time-related
>> classes are using methods like #asNanoSeconds. And numbers do not implements
>> it. But they do implement methods as #nanoSeconds, #milliSeconds, #seconds
>> and #asSeconds. Of course "5 nanoSeconds” are nicer than “5 asNanoSeconds”.
>> Maybe we can do something to maintain polymorphism?
>>
>> Uko

On Wed, Aug 19, 2015 at 3:21 AM, Chris Cunningham
<[hidden email]> wrote:
> To, #asNanoSeconds converts the time into the umber of nanosecond that the
> time represents.
> #nanoSeconds (and the others) create a duration that is to be added to the
> time or DateAndTime. The two do not end with the same things 0 and
> shouldin't.
>
> The first tells you how many they represent; the second builds duration.
>
> Probably not ideal names - but the intents are definitely different.
>
> -cbc

That is a fine distinction, and relatively hidden from someone reading
application code.  So the follow up question is how to make such
distinction visible to an application developer.  It would be nice to
hover over a message send to get a popup showing the "type" returned
and messages available.  From time to time I consider what Smalltalk
might be like where the return-type of a method is specified (i.e.
only the method return type, still not typing variables). Anyone know
of a programming language like that?

Return-typing might facilitate:
  * Static analysis making a return-type hover popup simple.
  * Static analysis of cascade message sends.
  * Definition of global conventions that a particular message always
returns a particular type, with automatic checking. Runtime violations
might be logged full-time, or only when running unit tests.  The
message return-type effectively becomes an interface definition and
the methods the implementation.

A return type might be:
* a class
* a trait
* a more narrowly defined "protocol" subset of messages, which might
help with static analysis for modularisation and minimising the
bootstrap.

cheers -ben

btw, I notice...
  * Number>>nanoSeconds returns a Duration,
  * Duration>>nanoSeconds returns an Integer.

Should the latter be renamed #asNanoSeconds, or perhaps #nanos in line
with its instance variable?  Indeed, perhaps all #asNanoSeconds should
be renamed #nanos, since its not converting to a NanoSeconds class.
If its being converted to a raw integer, presumably the context of its
usage will remain apparent plus the developer will have to
subsequently mange that.