Kris, Thanks for starting this thread.
I am all for getting the Lift APIs more normalized. It'd also be great if we could do a lot of it during the next month or so (prior to M8) because I'd really like M8 to be stable and the M8 phase be a bug-fix and 2.8 port phase. On Mon, Nov 16, 2009 at 11:59 AM, Kris Nuttycombe <[email protected] > 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? > I am firmly opposed to deprecation of the apply style of setting entities in Lift. Mapper (and Record) use the apply style very successfully. The apply style allows chaining of the setting of fields and that leads to much more readable code. Mapper initially used the update() and Pascal (:=) styles for assignment. Neither of these proved popular and are generally disused (I may have taken them out at some point). So, I'm all for Pascal style assignment to entities in addition to the apply() style, but the apply() style keeps things consistent with persistence libraries in Lift. > > 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. > I'm cool with this... but I don't know how many of these exist. I think only 1 or 2. > > 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, I agree and I've done a lot over the years to try to reduce them. Unfortunately, Seq and List (the places where the issue is most prevalent), are type-erased. I tried to get Martin to include Manfest on List for 2.8, but failed. > 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. > If you can do better, I'm all for it, but at least through the 1.0 I was very focused on this issue. The existing type erasure issues exist, but not through lack of trying to eliminate them. Thanks, David > The less we subvert the type system, the less likely we are to have > unexpected errors. > > Kris > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
