Very nice!
On Tue, Nov 17, 2009 at 10:16 AM, David Pollak
<feeder.of.the.be...@gmail.com> wrote:
> Okay, there's a simple answer that satisfies everyone:
>
> case class ParamCalcInfo(paramNames: List[String],
> params: Map[String, List[String]],
> uploadedFiles: List[FileParamHolder],
> body: Box[Array[Byte]])
>
>
> lazy val ParamCalcInfo(paramNames: List[String],
> params: Map[String, List[String]],
> uploadedFiles: List[FileParamHolder],
> body: Box[Array[Byte]]) = paramCalculator()
>
> No type erasure issues because the case class defines the types. Optional
> (and in my opinion, necessary for at the very least documentation purposes)
> type declarations on the variables. Better compiler enforcement than
> tuples.
>
> On Mon, Nov 16, 2009 at 10:30 PM, Kris Nuttycombe
> <kris.nuttyco...@gmail.com> wrote:
>>
>> On Mon, Nov 16, 2009 at 11:13 PM, David Pollak
>> <feeder.of.the.be...@gmail.com> wrote:
>> >
>> >
>> > On Mon, Nov 16, 2009 at 5:01 PM, Alex Boisvert <alex.boisv...@gmail.com>
>> > wrote:
>> >>
>> >> On Mon, Nov 16, 2009 at 4:26 PM, David Pollak
>> >> <feeder.of.the.be...@gmail.com> 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?
>>
>> The thing is, the compiler really *doesn't* do the right thing if you
>> supply the types. In fact, it will do the wrong thing if you change
>> the upstream code more frequently than it will do the right thing.
>>
>> Case in point: this compiles without complaint:
>>
>> object Test {
>> class A
>> class B extends A
>>
>> val (a: A, b: B) = (new A, new A);
>> }
>>
>> It will fail at runtime with a MatchError or ClassCastException or
>> something equally nasty. If the types were not annotated, then the
>> downstream code would fail to compile.
>>
>> Kris
>>
>> > (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 lift...@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=.
>> >
>> >
>> >
>> > --
>> > 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 lift...@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=.
>> >
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@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=.
>>
>>
>
>
>
> --
> 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 lift...@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=.
>
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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=.
