Difference between revisions of "Scala (Language)"

From Jtkwiki
Jump to navigationJump to search
m
Line 10: Line 10:
  
 
* The "value oriented" interpretation of the == operator seems problematic to me. What should the Scala programmer use to test for object identity?
 
* The "value oriented" interpretation of the == operator seems problematic to me. What should the Scala programmer use to test for object identity?
 +
 +
* Also, the interpretation of "x == y" as "x.==(y)" might result in an asymmetry (loss of commutativity) which may prove particularly problematic. I'd generally consider it a good idea to have a mechanism that just is commutative, rather than having to rely on adherence to some kind of contract to ensure commutativity where that is required.
 +
 +
* The "=>" modifier to delay evaluation of parameters seems interesting.
 +
  
 
[[Category:Computing]]
 
[[Category:Computing]]

Revision as of 05:01, 26 November 2011

Notes

On "An Overview of the Scala Programming Language" An Overview of the Scala Programming Language, Second Edition, by Martin Odersky et.al

  • The point of Scala's pattern matching feature is not quite clear to me.
  • Scala's "id: type" syntax is rather less easy to read than Java's "type id" syntax.
  • The "optional semicolon" idea is very problematic, delimitation of statements should be unambiguous, and the significance of tokens (whether semicolon or newline) should be unambiguous as well. Interpreting newline as a statement terminator if a statement terminator makes sense here is an idea that has wrought havoc in R already.
  • The "value oriented" interpretation of the == operator seems problematic to me. What should the Scala programmer use to test for object identity?
  • Also, the interpretation of "x == y" as "x.==(y)" might result in an asymmetry (loss of commutativity) which may prove particularly problematic. I'd generally consider it a good idea to have a mechanism that just is commutative, rather than having to rely on adherence to some kind of contract to ensure commutativity where that is required.
  • The "=>" modifier to delay evaluation of parameters seems interesting.