Consider propertymirror type that wraps getter and setter methods about reflectable.dart

[eernstg]

Thanks for the input, it's an interesting idea!

First, we made the choice to allow the getter name in a set operation because invokeSetter arose as a rename of setField (there was widespread support for renaming getField and setField from 'dart:mirrors' to invokeGetter and invokeSetter in reflectable, because that's what they actually do), and setField expects the variable name (for instance, x) rather than the setter name (x=). It is a little bit sloppy (because the actual name of the setter ends in '=', and because we can now use two different names for the setter). But it is probably not very harmful in practice, and you could claim that it is convenient.

Second, about PropertyMirror: It is an attractive goal to simplify the program under scrutiny in various ways, e.g., by adding some structure to the set of members, and grouping a setter and a getter with the same name is an obvious example. However, the language Dart does not really justify this grouping: If you have a variable x than you'll implicitly get a getter x and a setter x=; but you might as well have written an explicit getter named x, and inherited a explicitly written setter x= from a superclass. Even though it would be good style to make sure that those two independently created members are somehow semantically related, there is nothing in the language that forces them to be more related than any other pair of methods.

We won't rush to extend the palette of mirror types, but let's keep this issue around for collecting input on this kind of feature (extended member classification and grouping), with "getter/setter pair" as a prime example.

[lassedamgaard]

Just to clarify, I think it’s nice that you can invoke a setter using the getter name, no objection there.

Now with respect to the grouping of getters and setter I see your point but I don’t think it hinders providing the proposed “property” abstraction, as long as the semantics in such cases as you mention are described, whatever they may be. I mean in the vast number of cases getters and setters are actually semantically related as you would expect and if you want to exploit that such a relation is not really enforced by the language and do something retarded like e.g. overriding the getter of a superclass variable to return a different value than the one affected by the superclass setter it seems you’ve already shot yourself in the foot. In such cases I don’t think it matters much if a property abstraction that assumes a non-existing link cannot save you. That’s my immediate feeling anyway, without really having though about all the unspeakable ways in which this might blow up.

[eernstg]

We have decided that it is too much out of line with the design of other parts of reflectable to introduce PropertyMirror as a new intermediate type in the mirror hierarchy. MethodMirror has 12 classification related boolean getters, and even though several of them are interdependent (isGetter and isSetter cannot be true at the same time, regularMethod is true iff the method isn't a factory constructor, generative constructor, setter, nor getter, etc) it would still give rise to several other potential new kinds of mirrors whose purpose would mainly be to indicate constraints on the values of those 12 getters; e.g., x is PropertyMirror wouldn't do much more than x.isGetter || x.isSetter, and the rest of the members offered by PropertyMirror presumably wouldn't differ much from what MethodMirror offers already. So we decided that simplicity of the interface is more important than convenience in this case.