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?
Justin
