Re: syntatic sugar IN keyword.
Tom McGlynn wrote:
Lew wrote:
You can prevent recalculation of 'in()' results by passing the
returned 'Set' instead of recalculating it.
void method1( Foo x, Set<Foo> inset )
{
if ( inset.contains( x ))
{ ..., }
}
which seems silly. Just create immutable 'Set's of what you want to
model as sets, and use 'Set#contains()' to model containment within a
set.
void methodThatNoLongerNeedsMethod1( Foo x )
{
final Set<Foo> inset = Collections.unmodifiableSet( in( foo0,
foo1, foo2, foo3 ));
while ( reallyLongLastingCondition() )
{
if ( inset.contains( x ))
{ ... }
}
}
Depending on your logic, 'inset' can be local, instance or class
scope. Depending on the number of loop iterations, the use of a
'HashSet' under the hood can really help performance even for fairly
small sets.
This is not a verbose idiom, certainly not by Java standards.
It may not be appropriate for the invoking method to know the set of
alternatives -- they (and even the notion that there is some specific
list of alternatives used by the invoked method) may be fully
encapsulated in the invoked method which may be in some other class.
I'll get back to this valid point.
So I don't think Lew's approach of having the invoker know the
alternatives addresses the efficiency issue generally (in the
mathematical sense). However there are several idioms for
You're absolutely correct. I aimed only to show that there was at least one
place where you could obviate the problem, not to show a universal solution
even were there such a thing. As one typical idiom involving 'contains()' it
does demonstrate that existing Java code can already be reasonably compact in
this area.
One assumes in this group an audience who can generalize "there is a solution"
to "here's one that applies to my situation", not just parrot what they see on
Usenet. Nor do I presume here to provide a final answer - only one case.
initializing the Set which avoids having to code an explicit add for
each element -- which does look pretty clumsy imho. Given that, I'd
generally (in the common usage sense) agree with Lew that it's
typically straightforward to find some way to use Set.contains such
that the benefit of special syntax is limited.
One should never construe a post in this forum to contravene otherwise
unmentioned best practices.
Others in this thread had already alluded to
'new HashSet<Foo>( Arrays.asList( foo0, foo1, foo2, foo3, ... ))',
for example. Where one wants to get more verbose, as in the case Tom brought
up (full encapsulation of the logic in a method), one is doing it for a reason
outside the use of some fancy new 'in' syntax. Whatever 'in' would solve is
simply pushed down into that encapsulating method, where the matter of
existing Java idioms once again pertains.
Even if 'in' were deemed valuable enough to enter the language, as other
dubious idioms have been, you'd still need to know how to do it until the
feature enters, and how do to it when the feature's coverage isn't enough.
We face this now with 'enum'. In rare circumstances 'enum' isn't enough, and
it's worth leaving the compiler express lane to create one's own type-safe
enumeration class just like we used to back in Java 1.4 and earlier. It's
like using carbon paper when you're used to a photocopier - sure, it's messy,
but it works.
--
Lew
Never generalize. There are no absolutes.