Hi, all, This is just a starting point for debate with a hope of eventual consensus on something that's ultimately somewhat trivial matter. Since style is currently a topic of discussion on the main scala-users list, I thought it an appropriate time to bring it up.
Lift is one of the most prominent, perhaps the most prominent Scala applications in current existence, and as such I think it has a significant role to play in exemplifying good Scala style. At the same time, Lift has also been developed over the course of its' developers familiarization with the language, and so it displays some occasional stylistic warts. At the same time, major changes coming with Scala 2.8, particularly named & default parameters, may be something we want to take advantage of in ways that may have a substantial effect on usability of our APIs. I guess my general question is, how does the Lift community want to deal with the stylistic warts and naming inconsistencies, and how do we want to go about integrating some of these new features? In some cases, we may be able to use a strategy of giving some operations new names and deprecating the old, but in others this might lead to some really hacky looking APIs since we've already got good names, and changing their signatures might break a lot of code. Also, what are the big warts on Lift that ought to be resolved by renames or named/default parameters? Two naming issues that have come up recently in Lift internal discussions follow: First, Alex Boisvert suggested that S.init be renamed to S.doWith to have more consistency with Req and LiftSession. At least internally, I think that the consensus was that this wasn't necessarily appropriate. Second, I suggested the deprecation of the pattern of using apply() on AnyVar to provide setter functionality, since to me using something that looks like function application to do a mutation seems ill-conceived. My initial suggestion was to piggyback our functionality on the update() rewriting that is done by Scala, but on further reflection and David's feedback I realized that this would be even uglier since you'd have to use myRequestVar() = "foo". So, what would folks think about defining the symbolic method ":=" on both AnyVal and within the Mapper framework instead, with the goal of eventual deprecation of the apply style? Thirdly, I would like to propose that any "marker" traits (i.e. traits that declare no methods) within Lift either be sealed, or have the relevant methods tailored to the shared functionality they represent added (or both.) Match errors can be nasty, and sealing the traits (providing an extension point for users if need be) can help the compiler help us to eliminate that class of errors. Fourth, in compiling the Lift source I see far more warnings related to type erasure in match statements than I'm strictly comfortable with. My personal plan is to start working through these and eliminating them where possible, but in general I think that we as a community should start running all of our builds with all warnings enabled, and strive to eliminate them. The Scala type system can be complicated, but in my experience it is virtually always possible to avoid such warnings (and type unsafety!) with a bit of extra thought. The less we subvert the type system, the less likely we are to have unexpected errors. 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 -~----------~----~----~----~------~----~------~--~---
