2009/12/13 Kris Nuttycombe <[email protected]> > To this point, the only goals that have been recommended for this > effort are those that I've noted below: > > >> 1) Remove ambiguity wherever possible! There are a number of places > >> where very similar names are used to refer to utterly different > >> things. > > >> 2) As an aide removing ambiguity, consider outlawing or eliminating > >> extremely generic names, or else establish a single way in which a > >> given name will be used across Lift. Examples are Field, Info, Holder, > >> etc. > > >> 3) Avoid making the name of the return type part of the name of the > >> method. The types should tell the story as much as possible, except in > >> the case where multiple methods varying only in return type would > >> exist (illegal overloads) > > >> 4) Prefer Scala-style accessors and mutators. >
Thank you Kris for writing up these goals. I would like to add another one: 5) Avoid using abbreviations > In general, the principle goal of this effort must be improving the > clarity of the Lift API for both new adopters and for maintainers. 100% agreed! In order to make Lift even more popular it is essential to ease adoption. Often folks require better documentation and we all know that the code (the API) is the first and best source of documentation. Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
