On Mon, Nov 16, 2009 at 11:13 PM, David Pollak
<[email protected]> wrote:
>
>
> 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?
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 [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=.
>
>
>
> --
> 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=.
>
--
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=.
