On a related note, I suggest that the lift community read through the general Scala style guide proposed by Daniel Spiewak. Lift set a few norms of its own; I'm wondering what the reaction of the core team might be to some of the suggestions.
http://www.codecommit.com/scala-style-guide.pdf sincerely, chris Kris Nuttycombe wrote: > 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 -~----------~----~----~----~------~----~------~--~---
