Re: [Lift] Re: Lots of compile-time cruft
Very nice!
On Tue, Nov 17, 2009 at 10:16 AM, David Pollak
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
> wrote:
>>
>> On Mon, Nov 16, 2009 at 11:13 PM, David Pollak
>> wrote:
>> >
>> >
>> > On Mon, Nov 16, 2009 at 5:01 PM, Alex Boisvert
>> > wrote:
>> >>
>> >> On Mon, Nov 16, 2009 at 4:26 PM, David Pollak
>> >> 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.
>> > T
Re: [Lift] Re: Lots of compile-time cruft
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 wrote:
> On Mon, Nov 16, 2009 at 11:13 PM, David Pollak
> wrote:
> >
> >
> > On Mon, Nov 16, 2009 at 5:01 PM, Alex Boisvert
> > wrote:
> >>
> >> On Mon, Nov 16, 2009 at 4:26 PM, David Pollak
> >> 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 rece
Re: [Lift] Re: Lots of compile-time cruft
On Mon, Nov 16, 2009 at 11:13 PM, David Pollak
wrote:
>
>
> On Mon, Nov 16, 2009 at 5:01 PM, Alex Boisvert
> wrote:
>>
>> On Mon, Nov 16, 2009 at 4:26 PM, David Pollak
>> 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=.
Re: [Lift] Re: Lots of compile-time cruft
On Mon, Nov 16, 2009 at 5:01 PM, Alex Boisvert 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? (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=.
Re: [Lift] Re: Lots of compile-time cruft
On 17/11/09 5:26 AM, Kris Nuttycombe wrote: > > On Mon, Nov 16, 2009 at 4:33 PM, Kris Nuttycombe > wrote: >> On Mon, Nov 16, 2009 at 4:28 PM, David Pollak >> wrote: >>> Folks, >>> >>> I'm seeing a lot of: >>> [INFO] Unable to find resource 'javax.script:script-js:pom:1.0' in >>> repository specs-repository (http://specs.googlecode.com/svn/maven2/) >>> >>> Also, I know Kris turned on type erasure warnings because he wants to debug >>> them but there's just a pile that can't be fixed and these unfixable >>> warnings get in the way of real warnings... any compromise we can find on >>> this situation? >> >> Oops... I didn't realize I'd committed the pom with that in! I've no >> problem putting the extra warnings into a profile. Does Scala have an >> equivalent of or support the @SuppressWarnings annotation that you >> have in Java? >> >> Kris > > Actually, on further examination I claim innocence! git blame shows > the real culprit! :) > > I've moved the flags to a profile. > > mvn -Pdetail clean compile > > will give you all the warnings; basic usage does not. The real culprit speaketh :) -unchecked: making the build noisy, agreed. as long as the fixable ones get addressed, I am cool -deprecation: had been there before, and was a good thing imho. I am little hesitant having it turned off by default -Xno-varargs-conversion: had been there before, not sure if that generates any warning My mild concern is our muscle memory is still not used to the "-Pdetail" thing and we might not use it consciously on a regular basis. Some niggles could sneak through as a result. Either way, I am fine with reducing the cruft so long as this looks addressable and you guys consider this a decent compromise. - Indrajit > > Kris > >>> Thanks, >>> >>> David >>> >>> -- >>> 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 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 > -~--~~~~--~~--~--~--- > -- 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=.
Re: [Lift] Re: Lots of compile-time cruft
On Mon, Nov 16, 2009 at 3:33 PM, Kris Nuttycombe
wrote:
> Oops... I didn't realize I'd committed the pom with that in! I've no
> problem putting the extra warnings into a profile. Does Scala have an
> equivalent of or support the @SuppressWarnings annotation that you
> have in Java?
>
I'm not aware of any annotations that would suppress these warnings.
One solution to avoid the warnings would be to declare a class such as:
class UncheckedErasure[T](implicit m: scala.reflect.Manifest[T]) {
def unapply(x: Any) = x match {
case _ if m.erasure.isInstance(x) => Some(x.asInstanceOf[T])
case _ => None
}
}
and everytime we have an unchecked match, we could write, e.g.,
object uncheckedMap extends UncheckedErasure[Map[String, String]]
...
x match {
case uncheckedMap(map) =>
// do something with map
}
This gets us the same amount of compile-time and runtime type checking,
makes the unchecked matches stand out in code, remaining easily searchable,
at practically the same runtime cost.
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=.
Re: [Lift] Re: Lots of compile-time cruft
On Mon, Nov 16, 2009 at 4:26 PM, David Pollak 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. 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=.
Re: [Lift] Re: Lots of compile-time cruft
If something is a choice of a pattern match type annotation warning, or a plain
asInstanceOf, my personal preference would be the match.
-
David Pollak wrote:
On Mon, Nov 16, 2009 at 4:03 PM, Alex Boisvert wrote:
> On Mon, Nov 16, 2009 at 3:33 PM, Kris Nuttycombe <
> kris.nuttyco...@gmail.com> wrote:
>
>>
>> On Mon, Nov 16, 2009 at 4:28 PM, David Pollak
>> wrote:
>> > Folks,
>> >
>> > I'm seeing a lot of:
>> > [INFO] Unable to find resource 'javax.script:script-js:pom:1.0' in
>> > repository specs-repository (http://specs.googlecode.com/svn/maven2/)
>> >
>> > Also, I know Kris turned on type erasure warnings because he wants to
>> debug
>> > them but there's just a pile that can't be fixed and these unfixable
>> > warnings get in the way of real warnings... any compromise we can find
>> on
>> > this situation?
>>
>> Oops... I didn't realize I'd committed the pom with that in! I've no
>> problem putting the extra warnings into a profile. Does Scala have an
>> equivalent of or support the @SuppressWarnings annotation that you
>> have in Java?
>>
>
> 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.
Once again, this is historical (and there's a bug in Scala trac that Martin
closed after 2+ years asking for multiple assignment to not be done via the
pattern matcher).
>
> alex
>
> diff --git
> a/lift-base/lift-webkit/src/main/scala/net/liftweb/http/Req.scala
> b/lift-base/lift-webkit/src/main/scala/net/liftweb/http/Req.scal
> index ab574d4..2f3bf26 100644
> --- a/lift-base/lift-webkit/src/main/scala/net/liftweb/http/Req.scala
> +++ b/lift-base/lift-webkit/src/main/scala/net/liftweb/http/Req.scala
> @@ -313,10 +313,7 @@ class Req(val path: ParsePath,
> case _ => Empty
>}
>
> - lazy val (paramNames: List[String],
> - params: Map[String, List[String]],
> - uploadedFiles: List[FileParamHolder],
> - body: Box[Array[Byte]]) = paramCalculator()
> + lazy val (paramNames, params, uploadedFiles, body) = paramCalculator()
>
>lazy val cookies = request.cookies match {
> case null => Nil
>
>
>
> >
>
--
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 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
-~--~~~~--~~--~--~---
--
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] Re: Lots of compile-time cruft
On Mon, Nov 16, 2009 at 4:03 PM, Alex Boisvert wrote:
> On Mon, Nov 16, 2009 at 3:33 PM, Kris Nuttycombe <
> kris.nuttyco...@gmail.com> wrote:
>
>>
>> On Mon, Nov 16, 2009 at 4:28 PM, David Pollak
>> wrote:
>> > Folks,
>> >
>> > I'm seeing a lot of:
>> > [INFO] Unable to find resource 'javax.script:script-js:pom:1.0' in
>> > repository specs-repository (http://specs.googlecode.com/svn/maven2/)
>> >
>> > Also, I know Kris turned on type erasure warnings because he wants to
>> debug
>> > them but there's just a pile that can't be fixed and these unfixable
>> > warnings get in the way of real warnings... any compromise we can find
>> on
>> > this situation?
>>
>> Oops... I didn't realize I'd committed the pom with that in! I've no
>> problem putting the extra warnings into a profile. Does Scala have an
>> equivalent of or support the @SuppressWarnings annotation that you
>> have in Java?
>>
>
> 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.
Once again, this is historical (and there's a bug in Scala trac that Martin
closed after 2+ years asking for multiple assignment to not be done via the
pattern matcher).
>
> alex
>
> diff --git
> a/lift-base/lift-webkit/src/main/scala/net/liftweb/http/Req.scala
> b/lift-base/lift-webkit/src/main/scala/net/liftweb/http/Req.scal
> index ab574d4..2f3bf26 100644
> --- a/lift-base/lift-webkit/src/main/scala/net/liftweb/http/Req.scala
> +++ b/lift-base/lift-webkit/src/main/scala/net/liftweb/http/Req.scala
> @@ -313,10 +313,7 @@ class Req(val path: ParsePath,
> case _ => Empty
>}
>
> - lazy val (paramNames: List[String],
> - params: Map[String, List[String]],
> - uploadedFiles: List[FileParamHolder],
> - body: Box[Array[Byte]]) = paramCalculator()
> + lazy val (paramNames, params, uploadedFiles, body) = paramCalculator()
>
>lazy val cookies = request.cookies match {
> case null => Nil
>
>
>
> >
>
--
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 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
-~--~~~~--~~--~--~---
[Lift] Re: Lots of compile-time cruft
On Mon, Nov 16, 2009 at 3:33 PM, Kris Nuttycombe
wrote:
>
> On Mon, Nov 16, 2009 at 4:28 PM, David Pollak
> wrote:
> > Folks,
> >
> > I'm seeing a lot of:
> > [INFO] Unable to find resource 'javax.script:script-js:pom:1.0' in
> > repository specs-repository (http://specs.googlecode.com/svn/maven2/)
> >
> > Also, I know Kris turned on type erasure warnings because he wants to
> debug
> > them but there's just a pile that can't be fixed and these unfixable
> > warnings get in the way of real warnings... any compromise we can find on
> > this situation?
>
> Oops... I didn't realize I'd committed the pom with that in! I've no
> problem putting the extra warnings into a profile. Does Scala have an
> equivalent of or support the @SuppressWarnings annotation that you
> have in Java?
>
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...
alex
diff --git a/lift-base/lift-webkit/src/main/scala/net/liftweb/http/Req.scala
b/lift-base/lift-webkit/src/main/scala/net/liftweb/http/Req.scal
index ab574d4..2f3bf26 100644
--- a/lift-base/lift-webkit/src/main/scala/net/liftweb/http/Req.scala
+++ b/lift-base/lift-webkit/src/main/scala/net/liftweb/http/Req.scala
@@ -313,10 +313,7 @@ class Req(val path: ParsePath,
case _ => Empty
}
- lazy val (paramNames: List[String],
- params: Map[String, List[String]],
- uploadedFiles: List[FileParamHolder],
- body: Box[Array[Byte]]) = paramCalculator()
+ lazy val (paramNames, params, uploadedFiles, body) = paramCalculator()
lazy val cookies = request.cookies match {
case null => Nil
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Lift] Re: Lots of compile-time cruft
On Mon, Nov 16, 2009 at 4:33 PM, Kris Nuttycombe wrote: > On Mon, Nov 16, 2009 at 4:28 PM, David Pollak > wrote: >> Folks, >> >> I'm seeing a lot of: >> [INFO] Unable to find resource 'javax.script:script-js:pom:1.0' in >> repository specs-repository (http://specs.googlecode.com/svn/maven2/) >> >> Also, I know Kris turned on type erasure warnings because he wants to debug >> them but there's just a pile that can't be fixed and these unfixable >> warnings get in the way of real warnings... any compromise we can find on >> this situation? > > Oops... I didn't realize I'd committed the pom with that in! I've no > problem putting the extra warnings into a profile. Does Scala have an > equivalent of or support the @SuppressWarnings annotation that you > have in Java? > > Kris Actually, on further examination I claim innocence! git blame shows the real culprit! :) I've moved the flags to a profile. mvn -Pdetail clean compile will give you all the warnings; basic usage does not. Kris >> Thanks, >> >> David >> >> -- >> 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 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 -~--~~~~--~~--~--~---
[Lift] Re: Lots of compile-time cruft
On Mon, Nov 16, 2009 at 4:28 PM, David Pollak wrote: > Folks, > > I'm seeing a lot of: > [INFO] Unable to find resource 'javax.script:script-js:pom:1.0' in > repository specs-repository (http://specs.googlecode.com/svn/maven2/) > > Also, I know Kris turned on type erasure warnings because he wants to debug > them but there's just a pile that can't be fixed and these unfixable > warnings get in the way of real warnings... any compromise we can find on > this situation? Oops... I didn't realize I'd committed the pom with that in! I've no problem putting the extra warnings into a profile. Does Scala have an equivalent of or support the @SuppressWarnings annotation that you have in Java? Kris > Thanks, > > David > > -- > 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 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 -~--~~~~--~~--~--~---
