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.)