Re: [Pharo-users] mentoring contined I hope

[Roelof Wobben via Pharo-users]

--- Begin Message ---

Op 1-9-2020 om 00:22 schreef Richard Sargent:

On Mon, Aug 31, 2020 at 3:10 PM Roelof Wobben <r.wob...@home.nl> wrote:

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

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

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

Sorry to be throwing ideas but it is not better to keep everything in for examples minutes . So when I add minutes or substract minutes there does not have to make a new clock all the time.
I could then make the converting from minutes to hours and minitues when I want to display it.
So I have more flexiblility when for example the output format needs to be changed.



--- End Message ---