Ben Coman wrote >> On Tue, Aug 18, 2015 at 1:21 AM, Yuriy Tymchuk <
> yuriy.tymchuk@ > > 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@ > > 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. If you want to rename anything, rename the instance variable. Keep Smalltalk readable. As long as it is an English-based language, spell out words in English. (Similar rules apply regardless of the language one uses to write Smalltalk applications!) > 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. -- View this message in context: http://forum.world.st/method-return-typing-was-Re-Date-Time-api-tp4843929p4844098.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
