On Mon, Aug 31, 2020 at 1:57 PM Roelof Wobben <r.wob...@home.nl> wrote:
> > I would argue against that approach. Make it a requirement that a given > API must be used with correct values. > e.g. #hours:minutes: requires hours between 00 and 23 and minutes between > 00 and 59. > > If you want to convert equivalent time values, use a specific API. For > example, many time implementations publicly define a seconds-based API, > such as Time class>>#fromSeconds:. You can do the same with your > implementation with a class-side #fromMinutes: method. (The corresponding > instance methods would be #asSeconds and #asMinutes or something similar.) > > > > Moment, I do not know if I understand you right. > > so I would use the given method and use on the instance another function > that takes care of the converting to or a valid time object or for example > convert it to minutes and on display take care that a valid time is shown. > > Do I understand you right ? > I don't think you do, but it's a little difficult to determine. *Time hours: 0 minutes: 70* should throw an out of range exception on the second argument. Time fromMinutes: 70 "should" answer an instance equivalent to 01:00. (I say should in quotes, because Time is a point in time. Duration is something that makes more sense to have *Duration minutes: 70* be acceptable.) This discussion assumes *your* model of time uses just hours and minutes. Normally, Time includes seconds, and often fractions of seconds. But, you are working on an exercise, so a reduced scope Time may be appropriate. Rather than talking about Time class>>#fromMinutes:, let's go a little more extreme and discuss a hypothetical Time class>>#fromHours: method. We understand and agree that Time can represent hours from 0 through 23. There is no 24 o'clock. So, if you wrote *Time fromHours: 25*, what would you expect to get for a result? What would someone who comes along later and uses your code expect to get? It's not well defined. So extrapolate from that case to the other cases. 70 minutes is not a time. "I'll meet you *at* 70 minutes" said no one ever. :-) ["*in* 70 minutes" is a duration from the present moment, implying a time 70 minutes in the future.] I have come across a lot of code in my life. The hardest code to work with and to enhance is code that says it will try to accept whatever it's given. If it wants a number, it will accept a string of digits and "figure out" what number was meant. Life is so much easier when the author says "That's rubbish. Give me a proper number." or "That's too big. Give me a proper number of hours.", etc. In general, make your APIs precise and predictable. Range check the passed values and complain when they aren't proper. If the clock you are modelling has a precision of minutes, your API is #hours:minutes: and maybe just #hours: for convenience. (In general, I wouldn't do so.) And it's reasonable to have methods to answer the number of increments from the start of the day of your clock's precision and to create a new instance from that number. So, with a precision of minutes, you can have an instance method named e.g. #asMinutes or perhaps #totalMinutes or even #minutesSinceMidnight, and to have a corresponding *class* method #fromMinutes: or #minutesFromMidnight: which answers the corresponding instance of Time. If your clock has a precision of seconds, which is more normal for us, those "minutes" methods would actually be similarly named "seconds" methods instead. (If your clock has a precision finer than seconds, I would expect to see corresponding methods for the finer gradations of time that would be common, *in addition to* the various "seconds" methods. e.g. milliseconds or microseconds since midnight. And likely both if the clock resolution was microseconds, just because we do tend to think of milliseconds or microseconds when we talk of more precise times.) Just as the advice I gave you some months ago was to be unambiguous and precise when naming things, be unambiguous and precise about your APIs (all your methods, really!). People who end up using your code will thank you. > I send this personal because I cannot send to the mailing list according > to some spam list >
