Re: Argument scope
On Fri, 3 Dec 2010, Andreas Leitgeb wrote:
ClassCastException <zjkg3d9gj56@gmail.invalid> wrote:
Another case where Clojure comes to the rescue:
If lisp-style is the rescue, I'd rather stay captured. :-) (Just my
personal taste, not a judgement on clojure)
Btw., I do like Tom's suggestion ".addMeToo();", although I think there
could be cases where it wouldn't be obvious to the reader of some code,
which reference would really be re-used.
That's my main worry about it. Perhaps we should instead steal something
from Delphi:
BufferedWriter out;
with (out) {
write("foo");
newLine();
write("bar");
newLine();
}
Which basically redefines the implicit target of invocations inside its
scope from 'this' to something else. It's a little wordier.
Going back to the original idea, perhaps you could mark the receiver:
StreamHolder holder;
[holder.getBufferedWriter()].write("foo"); .newLine(); .write("bar"); .newLine();
Although if the rule is otherwise that it's the leftmost term of the
top-level expression (not sure i'm expressing that right), then you could
just use normal parentheses there.
Also, it might impede insertion of trace- logging code, as the following
".something()" would then pick up the tracer object, instead.
True. The 'with' form avoids that too. But then i think this notation is
intended for small runs of tightly-coupled operations, where you probably
wouldn't want to log in between them. Still, it would be bound to trip
someone up sooner rather than later.
If an object were designed for sequences of void method-calling, then it
should have its methods return "this", instead, so one could do
ref.callThis().callThat().callAnother(). ...
A construction which i hate with a burning passion. Why on earth does the
append method of a StringBuffer return a StringBuffer? In what sense does
that method evaluate to a StringBuffer? How does that have any semantic
meaning? It's a perversion of the normal rules of method design to
accomodate a particular usage, which is unacceptably awful. The syntaxes
were kicking around are ways of enabling that compact style without
needing to pervert the design of code.
tom
--
Now I am thoroughly confused. -- Colin Brace sums up RT3090 support
in Linux