«

Here is an idea for a new scope in Java (could be
used in other languages as well):

void fill
( final int color
{ final int RED = 1;
final int GREEN = 2;
final int BLUE = 3; })
{ /* ... */ }

Now one can call this as, for example:

fill( GREEN );

But one does not need to write

fill( Class.GREEN );

or so anymore.

The scope of the identifier »GREEN« is only the
argument expression corresponding to the parameter
»color«. So GREEN is not recognized here:

final int i = GREEN; fill( i ); /* not supported */

If »Beta« is an interface, one can also write:

void fill( final int color import Beta ){ /* ... */ }

, to »import« the constants of the interface Beta for
this purpose.

Or, we could have an import for Enum types:

void test( final enum Day import ){ /* ... */ }

, so that one then can write

test( MONDAY )

instead of

test( Day.MONDAY )

.

On Thu, 2 Dec 2010, Stefan Ram wrote:

> Here is an idea for a new scope in Java (could be
> used in other languages as well):
>
> void fill
> ( final int color
> { final int RED = 1;
> final int GREEN = 2;
> final int BLUE = 3; })
> { /* ... */ }
>
> Now one can call this as, for example:
>
> fill( GREEN );
>
> But one does not need to write
>
> fill( Class.GREEN );
>
> or so anymore.

I'd quite like that. Ages ago, i had the idea of being able to write:

class Paintbucket {
public static final int GREEN = 1;
public void fill(int colour) {...}
}

Paintbucket p;
p.fill(.GREEN);
// ^ leading dot indicates use of receiver scope

Static imports have made both our ideas somewhat redundant, though.

I also want a SmallTalk-inspired 'call this method on the same object as
the last statement' construct, which i'd also do with a leading dot:

BufferedWriter invoiceWriter;
invoiceWriter.writer(total);
..newLine();
..write(tax);
..newLine();

tom

--
Remember when we said there was no future? Well, this is it.

On 02-12-2010 01:42, Stefan Ram wrote:
> Here is an idea for a new scope in Java (could be
> used in other languages as well):
>
> void fill
> ( final int color
> { final int RED = 1;
> final int GREEN = 2;
> final int BLUE = 3; })
> { /* ... */ }
>
> Now one can call this as, for example:
>
> fill( GREEN );
>
> But one does not need to write
>
> fill( Class.GREEN );
>
> or so anymore.
>
> The scope of the identifier »GREEN« is only the
> argument expression corresponding to the parameter
> »color«. So GREEN is not recognized here:
>
> final int i = GREEN; fill( i ); /* not supported */
>
> If »Beta« is an interface, one can also write:
>
> void fill( final int color import Beta ){ /* ... */ }
>
> , to »import« the constants of the interface Beta for
> this purpose.
>
> Or, we could have an import for Enum types:
>
> void test( final enum Day import ){ /* ... */ }
>
> , so that one then can write
>
> test( MONDAY )
>
> instead of
>
> test( Day.MONDAY )

There are actually two questions:
1) is this a feature that is useful?
2) is this feature so useful that it is worth adding
to the complexity of the language?

I would tend to say YES and NO.

Arne

On Thu, 02 Dec 2010 21:39:59 +0000, Tom Anderson wrote:

> I also want a SmallTalk-inspired 'call this method on the same object as
> the last statement' construct, which i'd also do with a leading dot:
>
> BufferedWriter invoiceWriter;
> invoiceWriter.writer(total);
> .newLine();
> .write(tax);
> .newLine();

Another case where Clojure comes to the rescue:

(with-open [wr (BufferedWriter. source)]
(doto wr
(.write total)
(.newLine)
(.write tax)
(.newLine)))

It even has the same dot-method syntax. But Lisp parenthesization, so
(.write tax) instead of .write(tax).

As you can see, Clojure also has a handy shortcut for

BufferedWriter wr = new BufferedWriter(...);
try {
...
} finally {
wr.close();
}

and indeed it's easy to make a (with-open ...) like construct to scope
and release resources in general. It's like having C++'s RAII back, only
without the icky rest of C++.

ClassCastException wrote:
> Another case where Clojure comes to the rescue:
>
> (Clojure is the greatest **** since sliced bread)
>
> It even has (really groovy ****).
>
> As you can see, Clojure also (excels at saving the universe)
>
> and indeed it's easy to make (everything beautiful) in general.
> It's like having C++'s RAII back, only without the icky rest of C++.

But it is not Java.

Personally, I call "RAII" "RRID".

My personal "rescue" is just to type the extra lines of code. What, I'm going
to sprain my finger? At least I don't tar roofs for a living. That's an
honorable profession - those guys actually work for a living.

--
Lew
Oh, you proselyte, you!

ClassCastException <> 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. Also, it might impede insertion of trace-
logging code, as the following ".something()" would then
pick up the tracer object, instead.

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(). ...

On Fri, 03 Dec 2010 00:03:09 -0500, Lew wrote:

> ClassCastException wrote:
>> Another case where Clojure comes to the rescue:
>>
>> (Clojure is the greatest **** since sliced bread)
>>
>> It even has (really groovy ****).
>>
>> As you can see, Clojure also (excels at saving the universe)
>>
>> and indeed it's easy to make (everything beautiful) in general. It's
>> like having C++'s RAII back, only without the icky rest of C++.

Since you wrote the parenthesized expressions above, I take it you're a
convert?

> Personally, I call "RAII" "RRID".

"Resource Release Is Destruction"?

> My personal "rescue" is just to type the extra lines of code. What, I'm
> going to sprain my finger? At least I don't tar roofs for a living.
> That's an honorable profession - those guys actually work for a living.

One principle of sound software engineering is to try to specify each
fact in exactly one place -- cuts down on copy-paste errors and things
getting out of sync, not to mention saving typing, making code shorter
and more readable, and avoiding forgetting something the nth time you
reinvent wheel X.

Java lets you go pretty far with that with method and object
abstractions, but without macros and first-class functions it can not
quite get all the way there. Hence the repeated boilerplate Java code is
rife with, specifying over and over again how to "grab a stream, process
it, and then close it in an exception-safe manner" or "iterate over a
list removing some elements".

The with-open macro in Clojure addresses the former, however, and higher-
order functions combined with first-class functions and anonymous lambdas
take care of the latter. (The expression (remove #(= 0 %) foo) for
example returns a list that's a copy of foo with all the zeros removed;
if foo was (0 3 7 0 it gives (3 7 as its output. Clojure encourages
copying-with-modification in preference to in-place modification and
other thread-safe practices, though there are ways to do in-place
modification and you can even use the mutable java.util collections if
you really want to.)

As for how Java it is, it runs on the JVM, compiling to bytecodes; and
can use everything in Java's class library (except, IIRC, annotations,
support for which is forthcoming); so one might argue it's 2/3 Java.
(Others might argue that it's Java++. )

On Fri, 03 Dec 2010 08:16:56 +0000, Andreas Leitgeb wrote:

> 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.

Clojure solves that too.

(doto x
(y z)
(w foo))

operates everything on x. If there's more than one possible referent
there'll be more dotos, and then you know to pay attention to the
parenthesis nesting level.

> Also, it might impede insertion of trace- logging code, as the
> following ".something()" would then pick up the tracer object, instead.

Decorator pattern to the rescue? Wrap the object itself in a decorator
that logs some of the method calls, then punts to the wrapped object.
Then the decorator grabs the .something() as well.

(Clojure version would be to wrap the function whose uses you want to
log, e.g. (def f #(binding [*out* log-out] (println "f" %1 %2) (f %1 %
2))) which will append "f x y\n" to log-out on the way to calling the
original f if you now call (f x y).

> 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(). ...

I think there's a pattern name for this, too, and it's commonly employed
with factory objects.

FooFactory.withThis().withExtraSauce(42).withThat( "quux").create();

and the like.

ClassCastException <> writes:
>with-open

I have invented a means to do something similar in Java, but
one needs some time to read the article and grasp this idea:

http://www.purl.org/stefan_ram/pub/dual-band_if

Lew wrote:
>> ClassCastException wrote:
>>> Another case where Clojure comes to the rescue:
>>>
>>> (Clojure is the greatest **** since sliced bread)
>>>
>>> It even has (really groovy ****).
>>>
>>> As you can see, Clojure also (excels at saving the universe)
>>>
>>> and indeed it's easy to make (everything beautiful) in general. It's
>>> like having C++'s RAII back, only without the icky rest of C++.

ClassCastException wrote:
> Since you wrote the parenthesized expressions above, I take it you're a
> convert?

I was making fun of you. I expect to find you in an airport dressed in
saffron robes selling flowers to support Clojure.

Don't get me wrong - I find Krishna devotees to a person to be gentle,
sincere, deeply spiritual people.

Not so programming-language proselytes who pitch their off-topic spiel at the
merest hint of a whiff of a waft of aroma of possible relevance.

I do find it amusing, though.

--
Lew