Scala only really says 'not yet' to checked exceptions. If exceptions are a good idea (debatable, they make you lose referential transparency) then checked exceptions are a good idea, it's just that the syntax as in Java causes problems and Scala wanted to wait until a better mechanism was found.
The upshot is that exceptions are used less in Scala possibly in part *because* exceptions are unchecked, so checked exceptions would have to be done really well now to be attractive enough to add. On Oct 26, 2012 4:39 AM, "Kevin Wright" <[email protected]> wrote: > It's worth mentioning some of what Scala says "no" to then. > > Primitives > Static methods > Checked exceptions > Disjoint multiple constructors > null > Default mutable collections > Non-returning statements > Special-case syntax for string concatenation, catch blocks and Enums > > It can't say no to null entirely, not without losing compatibility, but it > certainly doesn't use it in any native libs. > On 26 Oct 2012 06:22, "Cédric Beust ♔" <[email protected]> wrote: > >> On Thu, Oct 25, 2012 at 2:58 PM, clay <[email protected]> wrote: >> >>> The companion objects vs static >>> The primary constructor system >>> The merging of separate fields/properties to eliminate pointless >>> JavaBean getters/setter or even the C# automation of getter/setters >>> The way that if blocks, for blocks, and aribtrary { } block return values >>> The way that immutable val is such a native construct >>> The addition of persistent immutable collections to the standard library >>> Pattern Matching >>> Native tuples >>> >> >> I agree with most of these points so my list would be pretty close to >> yours, but I'll add one important (to me) item: I want that language to >> contain very little on top of the features I want. >> >> I like my languages like I like my beef: lean. >> >> The problem with fat is that you can't just say "Ah well, I don't see the >> point in multiple inheritance of implementation, but I'll just ignore it". >> You can't ignore features in a language you don't like, you will encounter >> them whether you use them or not. And if you happen to be right in >> disliking a certain feature, it's almost guaranteed that when you encounter >> source code that uses that feature, it will make you unhappy. >> >> What makes a great language designer is not the ability to implement >> complicated pieces of the compiler but the simple ability to say "No". >> >> -- >> Cédric >> >> -- >> You received this message because you are subscribed to the Google Groups >> "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. >> > -- > You received this message because you are subscribed to the Google Groups > "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. > -- You received this message because you are subscribed to the Google Groups "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.
