Match.start, groupCount, and end should be properties, not methods

[DartBot]

This issue was originally filed by le...@google.com

---

What steps will reproduce the problem?

1. Use RegExp, get a Match
2. Try to find out where it starts and ends:

main() {
  Match m = new RegExp("h").firstMatch("hello");
  print(m.start);
}

What is the expected output? What do you see instead?

Expected: 0 Got: Object

It is not conceptually a method, as I am not telling the Match to start something.

What version of the product are you using? On what operating system?

DartPad, Dart Editor

Please provide any additional information below.

From http://www.dartlang.org/articles/style-guide/

DO use a getter for operations that conceptually access a property.

If the name of the method starts with get or is an adjective like visible or empty that's a sign you're better off using a getter. More specifically, a getter should:

Not take any arguments.
Return a value.
Be side-effect free. Invoking a getter shouldn't change any externally-visible state (caching internally or lazy initialization is OK). Invoking the same getter repeatedly should return the same value unless the object is explicitly changed between calls.
Be fast. Users expect expressions like foo.bar to execute quickly.

You should also consider adopting naming conventions for distinguishing properties and methods while you can still get away with renaming APIs and breaking everyone's code; for example the .NET style guide states that properties should generally be nouns and methods should start with verbs. (http://msdn.microsoft.com/en-us/library/bzwdh01d(v=vs.71).aspx) This not only helps users distinguish them but it also helps writers think about which they are writing.

As an example, hashCode() could either be made a property, or, if the point of making it a method is to let the user know it does something, then its name should be changed to something that suggests that it does something, like getHashCode() or even computeHashCode(). Because properties are a feature of this language, methods should not be named like they are properties; that just causes people to closurize them all the time. Methods get these kinds of names in languages that don't have properties; fight these habits.

[madsager]

Added Area-Library, Triaged labels.

[DartBot]

This comment was originally written by le...@google.com

---

I've reviewed all of dart:core, and here are the names I think should be reviewed for consistency.

Methods that should clearly be properties:

Match.start
Match.end
Match.groupCount

Other methods with nouns for names, many arguably should be properties:

Clock.frequency
Clock.now -- this is not a property, and while you could make it "getCurrentTime", "now" is common enough that I'm not sure it should change.
Hashable.hashCode
Iterable.iterator
Iterator.next
List.last
num.floor -- This is a noun, but I think of "floor" as a mathematical operation that you are asking it to do, like sin or abs, so I'm inclined to say this name is fine.
Queue.first
Queue.last
Stopwatch.frequency
Stopwatch.elapsed -- not a noun, definitely not a verb, best understood as short for "elapsed time" which is a noun
String.charCodes

Methods that could have been given nouns for names, but were not:

Map.getKeys
Map.getValues

Boolean methods/properties tend to ask a question and not be nouns, so more naming rules will need to be considered in this case. For these I don't see a discernable pattern to what you make methods versus properties:

Collection.isEmpty() (also Map, String, StringBuffer)
Date.isLocalTime()
Date.isUTC()
Future.hasValue
Future.isComplete
Iterator.hasNext()
num.isEven() (and other is methods on num)
TimeZone.isUTC

[justinfagnani]

Looks like all of these have been fixed, or are obsolete.

---

Added Fixed label.