Folks, Lift allows developers to create web sites that are:
1. Reliable (which includes secure) 2. Maintainable/concise 3. Highly interactive 4. Easy to build 5. High Performance 6. Easy to on-board (initial understanding of the APIs) Lift's APIs should reflect these rank-ordered goals. Some of these goals are in tension with each other. For example, easy on-boarding (e.g., longer method names, more traditional imperative style) is in tension with concise. There's also a very diverse Lift community. - I use Emacs for a lot of my Lift coding. I know folks who use TextMate for Lift coding. Having long method names assumes the use of an IDE which has name completion. Lift's APIs must serve both communities. - People are coming to Lift from Java, Ruby, PHP, and other backgrounds. Assuming Scala conventions rather than a "best choice" for naming does a dis-service to the polygots. Further, most of Scala's API conventions except for the collections stuff is not in my opinion that well thought out or consistent. - Many of Lift's APIs have evolved correctly based on actual usage patterns. For example, the initially counter-intuitive use of apply to set fields and vars works far better than any other mechanism, especially when chaining calls. I've tried many different mechanisms (e.g., update(), Pascal style :=, set(), etc.) for setting fields and the one that everybody gravitated to was apply(). We also have to consider the existing code base. I've personally got 150K lines of Lift-code under management. If we start breaking APIs without a compelling reason, it costs me money and it costs my clients less of my time. What's the impact to various different current users of Lift of breaking APIs without a compelling reason (and "I like this name better than that name" or "this name is more consistent" are not compelling reasons.) So, my criteria for any name changes (and this is not open to any type of negotiation and I've been 100% consistent about this since the discussion began) is: - If the name change can be accomplished with a deprecation of the old name without breaking any existing APIs, then the name change can be the "better" name. - If the name change is internal to Lift or is in a little-used feature (e.g., Kris's API changes in Loc) such that very few projects will likely be impacted by a name change and those that are impacted are sufficiently savvy that they will understand the change and be able to make it in a matter of minutes. - Any class name or object name change that does not meet the above criteria must be compelling. For example, we changed from Scala Actors to Lift Actors. This was a substantial amount of breakage, but there were no alternatives and the Scala Actor memory retention issues were materially impacting many different sites and we had worked on various attempted solutions over a 10 month period. If we're going to break without deprecation and the breakage is going to impact a substantial part of the Lift community, there must be a compelling reason to make the breakage. On Sun, Dec 13, 2009 at 10:49 AM, 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. > In general, this is okay, but if there's a FooHolder that holds a Foo, what's wrong with that kind of naming? > > >> 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) > I'd be interested in understanding what the specific examples are, but I'm not sure I'm on board with this. Sometimes getLiftResponse is a lot more meaningful than get. > > >> 4) Prefer Scala-style accessors and mutators. > I disagree. This is one where I have tried a lot of different accessors and mutators and the current crop is the best of breed. Sure, it's a little different, but it is much better. > > 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]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- 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.
