Re: Why we should (not?) have closures after all

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick May schreef:
Andreas Leitgeb <avl@xxxxxxxxxxxxxxxxxxxxxxxx> writes:
Patrick May <pjm@xxxxxxx> wrote:
Speaking in the abstract, consider the declaration of a standard
collection type in Java:
Map<String,Observer> registeredObservers = new HashMap<String,Observer>();
That's a lot of text, most of which Java programmers learn to skim over
quickly. Much of it is redundant. It is possible to retain static
typing, if you really want it, without requiring so much text. For
example:
registeredObservers = new HashMap<String,Observer>();
If you entirely get rid of any type spec before the variable, then the
distinction between merely setting a variable and declaring plus
initializing a new one is lost, and this could lead to nasty effects,
if instead of a local variable suddenly a field (Perhaps newly added
as "protected" to some base-class)

That's possible, but essentially an artifact of the syntax I
chose. A "var" keyword or a construct like
"new registeredObservers:HashMap<String,Observer>();" would achieve the
same goal. My point was that the explicit typing of Java does
significantly increase its verbosity.

registeredObservers = new HashMap();
The allowed types of the key and value can be determined from the
use of the variable at compile time.
No, no, That goes ways too far. This is where we leave the domain of
strict typing, which (unlike "repetitive verbose" typing) I don't
think we should leave.

That construct still allows for strong, if not completely strict,
typing. I agree with you that it probably doesn't fit well with
traditional Java style, but it still allows the compiler to catch type
errors.

The question is whether you want the compiler to catch type errors (of
course), or whether you want the programmer to see them (also, no?). In
you suggested reduced syntax, the compiler may have no problem with it,
but for the (maintenance) programmer, it is much more difficult to find
out what type a variable has.

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkkAisAACgkQBGFP0CTku6O0tACbBBI9iNzshjpqtuQz/Ga61RPy
bgYAoLrDBr4HtzbPxBDGN9MiDo23U9U9
=6eel
-----END PGP SIGNATURE-----
.

Relevant Pages

  • Re: Is there a "Large Scale Python Software Design" ?
    ... of cases where the programmer is reading too much into information returned from ... Slopping casting - the attitude that casts are needed only when the compiler ... they're cases where static typing appears to give an advantage in ... to differentiate between uninitialied and "not present", etc.), and refactoring ...
    (comp.lang.python)
  • Re: Cracking DES with C++ is faster than Java?
    ... Usually, Java is compiled into bytecode, which is somehow native code ... compiled into native code (by the "JIT" compiler). ... optimizations. ... A very good C programmer and a very good C++ programmer, ...
    (comp.lang.java)
  • Re: Cracking DES with C++ is faster than Java?
    ... Usually, Java is compiled into bytecode, which is somehow native code ... compiled into native code (by the "JIT" compiler). ... optimizations. ... A very good C programmer and a very good C++ programmer, ...
    (comp.lang.cpp)
  • Re: Cracking DES with C++ is faster than Java?
    ... Usually, Java is compiled into bytecode, which is somehow native code ... compiled into native code (by the "JIT" compiler). ... optimizations. ... A very good C programmer and a very good C++ programmer, ...
    (sci.crypt)
  • Re: Obstacles for Tcl/Tk commercial application development ?
    ... you to give hints to the compiler so it can catch the error. ... typing doesn't mean you have no type-induced errors in your code. ... language that uses strong static typing. ... As yourself point out above, one should strive to give as much information to as much as possible to everyone, including the programmer will have to maintain or use the code. ...
    (comp.lang.tcl)