Hi Fantom,

I'm very new to Fantom, from what I've observed, Fantom's naming convention on class/method names etc are very minimal, for example, Obj instead of Object, toStr instead of toString.

Which is OK as long as they make sense, but I think in some cases Fantom has over done it, for example, DateTime.min, my first reaction was it must be getting some "minimum value" of the DateTime, but it didn't make sense, then after I read the doc I realize the min in DateTime.min stands for minutes, which was surprising, as my (perhaps most people's as well) real world experience with min is that it stands for minimum, just like max is for maximum.

I think Fantom should be more careful about naming abbreviations, make it short & sensible, please don't make it short just for the sake of less typing.

Keep up the good work though.

+1 for suggestion.

DateTime.min as DateTime minimum was my first thought once I saw it. I guess minut or minute would be a way better convention. I hope brian deprecates it in favor of something more verbose.

Yes. This is inconsistence. min already used in Fantom as minimum.

+1 for minute.

+1 for minute.

I think .mn is better... Short and it is used in human languages

Code readability is very important, it directly affects how easy a program can be understood and maintained.

Shorter names does not mean it's more readable, it's how easy and quickly a name is going to processed by our brain determines the readability.

For example, when reading DateTime.min, our brains need to map min to minutes before we can understand what DateTime.min means, if our brains start doing this kind of mapping, it really slows us down. If we read DateTime.minutes instead, there is no "brain mapping" need to be done, which leads to quicker reading speed even though there is more character on screen.

+1 for DateTime.min to DateTime.minutes. But also DateTime.sec to DateTime.seconds (for completeness)

+1 for minute.

I don't personally think min is confusing because you never use it out of context from hour, sec, etc:

Time(ts.hour, ts.min, ts.sec)

I'm also not sure we would ever use min/max as the method names on DateTime. But all that said, I don't really have a problem deprecating it with a method called "minute".

Before I'd consider that thought would want to hear more votes to ensure it is a fairly unanimous sentiment.

Don't really think this a big deal either - but I could live with minute.

-1 for minute.

I think DateTime.min is a good name. min is a common acronym both for minute and minimum (for example, http://acronyms.thefreedictionary.com/MIN). I don't see any reason to give every acronym unique meaning. For example it's OK to have the same name for window.close and socket.close while meanings are different. As @lae mention, minimum value of the DateTime doesn't make sense, especially because DateTime.min is instance method, not static.

Keep in mind that min can be used for Duration literal and I think 5min looks as clear as 5sec or 5ns.

min does seem worse than minute. I'm a big fan of "complete" names for things.

For dates I also prefer to write dayOfMonth rather than date or day since those are pretty confusing - day is ambiguous as to whether it's the day of the year/week/month and date is the whole thing we're looking at. In Fantom's Date API you see dayOfYear but just day for the dayOfMonth. That's not as bad, at least for people already used to this convention, but in priciple it's ambiguous and less orthogonal.

However, I suspect that min -> minute would be enough of a concession from a team that obviously goes the other way and likes it short and sweet.

A min method on a Date would likely take two dates and return the earlier of the two. If you added that method later you might wish to make it as static method called min and if someone wanted to refer to that method they'd probably call it Date.min just like the one that now returns the position of the minute hand.

My 2 pence worth...

I'm a big fan of explicit and in today's world of [CTRL] + [Space] and auto-completion I see no advantage of short acronyms over longer complete names.

Acronyms and abbreviations, due to their very nature, do (and will) lend themselves to ambiguous meanings in various situations and languages. Explicit names, however, do not.

Just because you "get" the intended abbreviation does not mean everyone else will.

TTFN,

Steve.

+1 for minute

You read code far more often than you write it therefore I always favor readability over reducing a few keystrokes. I don't favor any abbreviations unless its so common as to be part of the normal lexicon such as "Int" or "Bool". However if I had a choice I would even want those spelled out as Integer and Boolean but that ship has sailed and I'm arriving at the dock a bit late. :)

Readability always wins IMO!

Can someone explain to me the philosophy behind Fantom's naming convention?

I just saw a couple of methods, List.ro and List.rw, what the......

http://fantom.org/doc/docLang/Conventions.html#naming