On Mon, Nov 16, 2009 at 1:22 PM, David Pollak <[email protected]> wrote: > 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. >
They're not there now. I'll open a ticket to add the Pascal style assignment method where appropriate and provide a patch - I figure that the update() syntax is so ugly that people probably aren't keen to use that one so I'll leave it out unless someone is interested. >> >> 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. Yeah, it's not a huge problem. Will ticket & patch, and check back if I have any questions. > >> >> 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. Okay, I'll see what I can do on a case-by-case basis. The other thing I'm interested in is the named and default parameters syntax. The first place I know of that could benefit from this is in the multiple definitions of bind() - what others are folks aware of? 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 -~----------~----~----~----~------~----~------~--~---
