On Wed, 3 Oct 2012, Justin wrote:
On Wed, 3 Oct 2012, Rafael Schloming wrote:
I believe the convention I'm following is actually the norm (for a good
reason). The get/set_foo
pattern is used for passive slots, i.e. it's a strong signal that if you
call set_foo with a given
value then get_foo will return that same value until set_foo is called
again. Whereas
dynamic/computed/derived values (something where it would never make sense
to have a setter) are
generally not prefixed by get. Some examples in Java would be things like
Collection.size(),
Object.hashCode(), Map.values(). I think this is a pretty valuable
convention as it is a signal that
I agree that's a common convention in java. It's not "the norm":
counterexamples are Thread.getState(), Integer.getInteger(s),
File.getFreeSpace().
In any case, it's arguably a good convention. It has one particular
practical problem, more collisions. This problem is exhibited right now in
pn_link_drained. What does that do? It *looks like* it is a dynamic
predicate, but it isn't. If in the future you want to add such a predicate,
you'll have a collision. _get_ keeps things cleanly separated. (In the case
of pn_link_drained, I think that just needs a better name.)
I'm pleased we're discussing this. Can we discuss it (and all the other
things worth discussing, imo) before we set down changes in the code?
I've updated the proposal again. I've also adjusted the Java naming to
match the C naming in the main. Of course, they needn't work the same
necessarily, but for instance, I figured that if we're going to
distinguish between computed/derived and passive attributes in C, we ought
to as well in Java.
Justin
