I agree very strongly that this is the principle goal. A good name expresses what it refers to succintly, and if that is not enough to inform one exactly what it is, once one learns what it is then he sees how "obvious" it is from the name and it is an efficient, effective reminder. (If something can be obvious after you learn it, but hopefully you know what I mean. :) ) Similarly if you know what you want to do it would be easy to remember its name. I wish I had more time to work on this, but in any case there isn't much to talk about until the goals are finalized. Maybe it would be worthwhile to compose a list of potential goals, even ones that are questionable, and hold a vote on each of them on the list? In any case, I think it's unrealistic to hope to have a perfect API in all of LIft by 2.0, but on the other hand too unambitious to just deal with names as they are questioned, if they are. We want Lift to have a good reputation in terms of API design. Maybe we should decide to tackle one module at a time, one package at a time, and maybe even one class at a time, systematically. If we can cover net.liftweb.http by 2.0, it would be superb. But I think systematic is very important, because otherwise the results will be half-baked. So I vote for an on going, but systematic process--it need not have time constraints but someone needs to take one name at a time, throw all the guidelines at it (which btw should end up in a wiki IMHO), and then raise discussion on the list if applicable. It doesn't matter how long it takes, because slowly but surely we will see clear results. Similarly, Review Board posters and reviewers should accept responsibility to follow all naming guidelines as best as possible. Hoping to hear feedback. :)
------------------------------------- Kris Nuttycombe<[email protected]> wrote: 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. In general, the principle goal of this effort must be improving the clarity of the Lift API for both new adopters and for maintainers. We now have two days before the "goal discussion" closes. If anyone has any additional objectives they'd like to voice before this window closes, please do so now. I'd like to hold a vote on the proposals above as well as any other objectives folks may have tomorrow, so that any -1's can be ironed out before the 15th. Kris -- 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. -- 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.
