On Wed, Oct 03, 2012 at 08:35:00AM -0400, 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().
Agreed. The above APIs were a legacy of the pre-standardized APIs IIANM. > 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? +1 I find APIs of the form pn_verb_object to be extremely expressive, making the source code much more readable. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
pgp1c7v06PB1A.pgp
Description: PGP signature
