search

onekiloparsec / SwiftAA

The most comprehensive collection of accurate astronomical algorithms in (C++, Objective-C and) Swift.
http://www.onekiloparsec.dev/
MIT License
172 stars 31 forks source link

Suggestion: convert functions without parameters and side-effects to computed properties #25

Closed alex-vasenin closed 7 years ago

alex-vasenin commented 7 years ago

We have a lot of functions without parameters and side-effects like Hour.inMinutes(), JulianDate.date(), ArcMinute.inDegrees(), etc which perfectly fits in computed property paradigm. What do you think?

onekiloparsec commented 7 years ago

Well, first there were computed properties. And I recently changed to functions, for readability reasons (at least to me).

In these type of objects, I find that computed properties are giving access to some part of the concept itself. For instance, a computed property .minute (or .minutes) to a Hour object means, I think quite logically, that you return the minutes part of the hour. Not an "entire" new object obtained from the first one.

Quite literally, the .minutes we want to return is not a (computed) property of the original object.

So .inMinutes() to me better express the fact that we take an object, and returns a new one expressed with a new physical unit. It is not just a part of the original object.

What do you think?

onekiloparsec commented 7 years ago

I see these .inSomething() in a way similar to the .toString() in Java. (If one of my former colleague discover that I refer to Java to justify a Swift API decision, he will laugh to hell.)

alex-vasenin commented 7 years ago

It makes sense for Java indeed, but they are look weird in Swift (well, at least for me). Not a big deal frankly, but have a look, for example, at reference for Double from Swift Standard Library or at computed property example from The Swift Programming Language.

onekiloparsec commented 7 years ago

Thanks for the refs. I am generally all in favor of adopting standards. I will have a look at these refs once the Christmas dinner is over (in quite a few hours from now). Merry Christmas! And thanks for the great work. SwiftAA will look good in a few weeks from now for a 2.0.

alex-vasenin commented 7 years ago

Merry Christmas! 😀

onekiloparsec commented 7 years ago

Ok, by keeping .in as prefix, we maintain readability, while still avoiding the confusion I mention above.

alex-vasenin commented 7 years ago

I just came across this interesting document. Definitely worth reading.

onekiloparsec commented 7 years ago

Thanks. Will definitely read it again, and see what should be improved in SwiftAA interfaces.