On Tue, Aug 18, 2015 at 1:21 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> 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 <cunningham.cb@gmail.com> 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.