mentoring contined I hope

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

On Mon, Aug 31, 2020 at 3:10 PM Roelof Wobben <[hidden email]> wrote:

Op 31-8-2020 om 23:45 schreef Richard Sargent:

On Mon, Aug 31, 2020 at 1:57 PM Roelof Wobben <[hidden email]> 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.)

I understad but here im stuck at what the person who made this challenge has said.
And unfortunalty  he/she has deciced that what I said earlier the code schould convert invalid time objects to valid time objects.
If I have made this myself I would make it as you said so  when a time in invalid thrown a error.

I understand. You have constraints. In that case, where you would do validation in #hours:minutes: (class side), do normalization instead. If either argument is out of range (starting with the minutes), keep the remainder and add the excess to the next value. If hours go out of range, discard the excess. You may need to tolerate negative values. The arithmetic is still straight forward. If not, you still need to validate for them.

Roelof

So still on the class side make code that convert any given hour and minute to a valid one ?

Yes. Such code would also be used when doing arithmetic with Times. e.g. if you were to implement an instance method named #addMinutes:, its implementation would be as simple as ^Time hours: self hours minutes: self minutes + anInteger (assuming the argument has that name). The instance creation method would normalize the new requested time, just like Time hours: 0 minutes: 70 would do.

Roelof

What is the value of self when the error occurred? The debugger should show you this.

Op 1-9-2020 om 21:11 schreef Richard Sargent:

You will discover an error when you write your tests, but that's fine. It's why you write tests. :-)

#validateTime:minute: is a poor name choice for a few reasons.
- there is no validation going on. Validation would report an error for invalid data.
- there is nothing to suggest what the first argument is, the counterpart to "minute:".
- it doesn't suggest there will be a new Time ("Clock") created.
- it's a "verb phrase" saying it will *do* something rather than answer something (I'm being vague here. Sorry.)

I suggest #normalizedForHour:minute:.
It explains that it will normalize the values and that it will answer a normalized result (it still isn't great, as it doesn't explain what).
Perhaps better would be #newNormalizedForHour:minute:.

Thanks,

I think I found the error

and solved it

hour: anInteger minute: anInteger2
    ^ self new
        hour: (anInteger2 // 60 + anInteger) % 24;
        minute: anInteger2 % 60;
        yourself

instance side :

printOn: aStream
    ^ aStream
        nextPutAll: self hour asTwoCharacterString;
        nextPut: $:;
        nextPutAll: self minute asTwoCharacterString

and the tests are green

now time to sleep and tomorrow time to figure out how to add and substract minutes.
As I remember it right you gave already the answer to me somewhere in our conversation

Roelof