[aspectj-dev] steele on locals, principles of language design

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

fyi, a relevant excerpt from 
  http://java.sun.com/features/2003/05/steele_qa.html

basically:
-- avoid similar correct programs
-- minimal invariants for Java extensions:
- locals private
- type-safety
- left-to-right order of evaluation
- symmetric and transitive equals

AspectJ preserves these, except that there is no
guarantee about evaluation order for pointcuts.

This suggests points of comparison between AOP languages
and using API's or XML to drive interception mechanisms:

- API's/XML use data to distinguish before/after/around
  and to specify pointcuts, so it might be harder to 
  recognize mistakes in crosscutting specifications.

- API's/XML often use reflective implementations, so 
  type-safety is not preserved at compile-time.

- XML is taken as a specification by frameworks,
  so the resolution time is deferred at least until
  a separate build step, if not until runtime.
  
  This may actually fit more naturally into the workflow
  of the relevant developers; e.g., for component-based
  or distributed architectures, there's an argument
  for deferring aspect resolution until application
  assembly or deployment time.

Wes

-----------------------------------------------------------
-- question (Janice Heiss)
In what ways would it be a mistake for the Java programming 
language to grow? What are some pitfalls? What are the wrong 
directions it could take?

-- answer (Guy Steele)
Well, to be very abstract about it, every time you grow a
language, you increase the total number of text strings that are
correct programs. It's important to keep the correct programs at
some distance from each other, so that mistakes are less likely
to turn one program into another correct program that isn't the
one you wanted.

So, for example, I think it would be a mistake to extend the
language to the point that

for (int i=0, i<n, i++) System.out.println(i);

would be considered correct code, even if I had some very clever
reason why using commas instead of semicolons could convey some
useful twist, because it would be too easily confused with the
usual

for (int i=0; i<n; i++) System.out.println(i);

Also, there is power in knowing that there are some things that
you just can't say in a language. It's really helpful to a
programmer to know that, for example, local variables are
effectively "private" and so another method can't unexpectedly
alter the value of a local variable. It's such a valuable
principle that I think it would be a bad idea to extend the
language to allow methods to access each other's local variables.

Designing a good programming language isn't just a matter of
throwing together a set of features; it's a matter of
establishing important principles that the programmer can rely
on. It's important to follow those principles as a language is
extended. Sometimes the principles themselves can be extended,
but only with great care. Here are four examples of important
principles in the Java language: local variables are private, you
can't violate the type system, the evaluation order goes from
left to right, and the "equals" method is symmetric and
transitive.