On 2 June 2011 19:11, Ricky Clarkson <[email protected]> wrote:
> > Interestingly, Scala can declare a thrown exception that Java will force
> you
> > to catch, via the @throws annotation
> > But it'll never force you to catch them at a time that's inconvenient for
> > you.
>
> Or tell you about it. That said, you might be able to write some
> bytecode processor that produces a report for all your bytecode that
> hides checked exceptions. Though I imagine you'll still lose some in
> the Function traits.
If anything, Scala's more likely to go the other direction. Allow you to
specify that a particular exception may *never* be thrown from a given
method.
Could prove interesting in combination with subclassing and template
methods, as well as with functional composition.
> Imagine performing an operation in parallel on an array of 100 elements,
> and
> > 2 of those invocations throw.
> > Checked exceptions state that you *must* catch a checked exception
> (though
> > we all know that remoting and threads can break this)
> > Unchecked exceptions, you can bundle together in an aggregate, but how
> could
> > the enforced catch behaviour best be handled?
>
> Ideally when you read the results you'll see the exceptions. That's
> how SwingWorker works now, and I think it's how Future works.
>
> > Compare
> > HashMap<Shape, Pair<String, String>> shapeInfo = makeInfo()
> > to
> > val shapeInfo: HashMap[Shape, (String, String)] = makeInfo()
>
> HashMap[Shape, Pair[String, String]] shapeInfo = makeInfo()
>
NO! It's:
*final *HashMap[Shape, Pair[String, String]] shapeInfo = makeInfo()
according to your own syntax.
...and *that* is why val/var are so important, it's impossible to
accidentally make something mutable simply by forgetting to enter a keyword.
Out of curiosity, let's assume it was meant to be mutable, so not final.
- How would you write the same line using type inference?
- How easy would it be to read a block of such declarations, some using
inference and some not?
I personally find this very readable (the (String, String) sugar is
> nice too). It's the angle brackets in the Java version that make it
> harder to read, especially in a proportional font like the one I'm
> reading these emails in.
>
> > Plus, you have the ability to invoke methods on any Int (primitives don't
> do
> > this)
> > So `2.toString` is a valid Scala operation.
>
> The same in C#, though there it's spelled 2.ToString() Because That's
> What C# Looks Like. And int is a primitive in C#. And you can do
> List<int> in C#. The syntax differences between primitive and
> reference types are just a Javaism, and nothing inherent about
> primitive types.
I disagree, primitive types have a very privileged place in Java. This
isn't just about not using object dot notation to call methods on them, or
whether they're named with an uppercase or lowercase letter, or even the
fact that they're the only kind of thing in Java that's permitted to use an
operator (other than String, which is so special that it forces everything
else to be a string when *it* uses a +).
They enjoy stack allocation when passed as method arguments, and Arrays of
primitives get VIP types, allowing them to be used without boxing/unboxing.
There's a unique performance benefit to be had for primitives in the JVM
(as it currently stands). Java syntax simply reflects this special place.
> > val tags = for {
> > page <- site.pages
> > tag <- page.tags
> > ucTag = tag.toUpperCase
> > } yield ucTag
> > and that's just a short example, not even using a filter. The difference
> > between <- and : helps indicate that this construct really isn't a loop.
>
> Why do you need to indicate that it's not really a loop? yield
> already does that. And if you didn't have yield it would really be a
> loop.
>
No, it wouldn't. It would still be a for-comprehension, just one that
relied on side effects.
> > Scala's grammar is approximately 1/3 of Java's. When counting
> > non-whitespace lines from the respective BNF descriptions of the two
> > languages, as taken from the official specifications.
>
> Is Scala's BNF up to date?
>
Yes
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" 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/javaposse?hl=en.
>
>
--
Kevin Wright
gtalk / msn : [email protected]
<[email protected]>mail: [email protected]
vibe / skype: kev.lee.wright
quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda
"My point today is that, if we wish to count lines of code, we should not
regard them as "lines produced" but as "lines spent": the current
conventional wisdom is so foolish as to book that count on the wrong side of
the ledger" ~ Dijkstra
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" 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/javaposse?hl=en.
