On Mon, Nov 16, 2009 at 11:59 AM, Kris Nuttycombe <kris.nuttyco...@gmail.com > wrote:
> 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. > Just to clarify, I think DavidP's position was that it's wasn't worth breaking code for this rename and that it wasn't entirely clear that S.doWith() was appropriate given there's also S.initIfUninitted(). Personally, I think S.doWith() and S.doWithUnlessInitted() would be better names but I can appreciate that people want the least amount of breaking changes from one release to another. Deprecation warnings would be good but complexify the codebase in the near term... I don't feel strongly about this either way. Just curious about what other people think with respect to this small but breaking changes. 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'm all for this, including using :=. > 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. > Agreed. > 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. > Agreed. alex --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
