On Mon, Nov 16, 2009 at 5:01 PM, Alex Boisvert <[email protected]>wrote:
> On Mon, Nov 16, 2009 at 4:26 PM, David Pollak < > [email protected]> wrote: > >> Speaking of warnings, which do you prefer (see patch below): >> >>> >>> 1) Explicit types on val extractors (as it is today) >>> 2) One-liner with no types (proposed) >>> >>> We could save 4 warnings... >>> >> >> Here's the cost of the 4 warnings: >> >> If you remove the type information and the lazy calculator thing changes >> how it does calculations, you'll silently get changed types (this has >> happened before) and that breaks things. On the other hand, if we leave the >> code with explicit types, we'll get a match warning (with the type erasure >> stuff turned back off) if the type change. >> > > You get breakage if the types change in an incompatible manner in both > cases. > > I don't see how you get any added safety by adding the types explicitly. > You get type-safety in downstream code... the code that is accessing the variables. You also avoid type inferencer problems. The type inferencer doesn't always give you what you expect (it's not like Haskell). Being explicit about what you expect is going to insure that the compiler does the right thing, even if it issues a spurious warning. So, why am I harping on this? (1) This code was stuff I worked on to get right back in 2007. It's stable and despite the aesthetic displeasure of a spurious warning, it does not need to change. (2) This code reflects a lot of work "getting it right" with the Scala compiler back when the Scala compiler was less stable. I know the code currently works and I don't remember what kind of weirdness other variations on the code caused, but I don't want to find out if there are latent issues with the Scala compiler. (3) From a priority standpoint, this is suboptimal. It's suboptimal for me to have to sell you on why it should not be changed. It is suboptimal because there are open tickets for some real issues that real users need addressed. If your bent is more oriented to getting to know the code, there's plenty of ScalaDocs and higher level documentation to write. (4) from a readibility standpoint, I like the code the way it is and it's most likely that if there's a problem or enhancement in that part of the code, it's me or Marius that're going to be fixing it. > In both cases, the compiler has the same information about the types and > perform the same amount of type checking for you. > > > alex > > -- > 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]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=. > -- 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=.
