Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Swing is dead! Long live Swing.

Reply
Thread Tools

Swing is dead! Long live Swing.

 
 
Lew
Guest
Posts: n/a
 
      02-29-2012
Wanja Gayk wrote:
> markspace wrote:
>> ... For situations where I might be tempted to just use strings,
>> I try to substitute enums. For example, instead of
>>
>> bind( someComponent, "event-name" );
>>
>> I'd use this:
>>
>> bind( someComponent, Events.NAME );
>>
>> It provides automatic syntax checking, and is much easier to refactor if
>> names need to be changed or moved around later.
>>
>> Any thoughts on this idea?

>
> I think the same way.
> I'm even going further and strongly propose preferring Enums to boolean
> parameters and this is why:
> http://brixomatic.wordpress.com/2010...olean-harmful/


+1

This might irritate those who already find Java verbose, since 'String's are
more compact to declare, but type safety and refactorability [sic] is a payoff
in many situations.

I'm even worse, because I pump a "friendly" string representation into the enum.
<http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html#toString()>
«An enum type should override this method when a more "programmer-friendly"
string form exists.»

Necessitating a corresponding 'public static E fromString(String rep)'.

'fromString()' compares 'toString()' strings first; if those fail it delegates
to 'valueOf()'.

<sscce source="eegee/Essential.java">
package eegee;
/**
* Essential {@code enum} implementation with "friendly" representation.
*/
public enum Essential
{
FOO("foo"),
BAR("bar"),
FANCY("fancy form"),
ANOMALY("useful to hold log or error messages"),
;
private static final long serialVersionUID = 1L;

private final String representation;

/**
* Constructor setting the friendly representation.
* @param rep String friendly representation of constant.
*/
private Essential(String rep)
{
this.representation = rep;
assert this.representation != null;
}

@Override
public final String toString()
{
return representation;
}

/**
* Look up enum constant from String representation.
* @param rep String representation of enum constant.
* @return Essential constant matching the representation.
*/
public static Essential fromString(String rep)
{
if (rep == null)
{
return null;
}
for (Essential value : values())
{
if (rep.equals(value.toString()))
{
return value;
}
}
return valueOf(rep);
}
}
</sscce>

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      02-29-2012
On 12-02-28 06:19 PM, Wanja Gayk wrote:
> In article <jidthv$psp$(E-Mail Removed)>, -@. says...
>
>>> I've been frequently annoyed by tools that do their binding by matching
>>> Strings to classes or component names, because every time you move,
>>> refactor or mistype something you're bound to get screwed. And it likes
>>> to happen in the worst possible moments. I'd rather avoid it, if I have
>>> the choice.

>
>> I tend to agree, strongly. For situations where I might be tempted to
>> just use strings, I try to substitute enums. For example, instead of
>>
>> bind( someComponent, "event-name" );
>>
>> I'd use this:
>>
>> bind( someComponent, Events.NAME );
>>
>> It provides automatic syntax checking, and is much easier to refactor if
>> names need to be changed or moved around later.
>>
>> Any thoughts on this idea?

>
> I think the same way.
> I'm even going further and strongly propose preferring Enums to boolean
> parameters and this is why:
> http://brixomatic.wordpress.com/2010...olean-harmful/
>
> Kind regards,
> Wanja
>

This little sub-thread I would have re-declared a few posts ago. You
guys are advancing good ideas, but confusing the issue by making it
sound like, in the context of the original discussion, that the end-user
developer of FXML is going to be worried about these details when in
fact he or she is not: it's the tools builder who is.

That changes the discussion radically. Tools often use techniques and do
things which sometimes cannot be recommended for the developer pool at
large, because they are tricky and/or dangerous, and only above-average
programmers ought to be doing things like that.

I happen to agree in general that you use enums when you can. I don't
see what these recommendations for Joe Average Coder have to do with a
discussion of potential tool support for FXML.

AHS
--
-- Gaiety is the most outstanding feature of the Soviet Union.
Josef Stalin, November 1935

 
Reply With Quote
 
 
 
 
Daniel Pitts
Guest
Posts: n/a
 
      02-29-2012
On 2/29/12 12:00 AM, Lew wrote:
> Wanja Gayk wrote:
>> markspace wrote:
>>> ... For situations where I might be tempted to just use strings,
>>> I try to substitute enums. For example, instead of
>>>
>>> bind( someComponent, "event-name" );
>>>
>>> I'd use this:
>>>
>>> bind( someComponent, Events.NAME );
>>>
>>> It provides automatic syntax checking, and is much easier to refactor if
>>> names need to be changed or moved around later.
>>>
>>> Any thoughts on this idea?

>>
>> I think the same way.
>> I'm even going further and strongly propose preferring Enums to boolean
>> parameters and this is why:
>> http://brixomatic.wordpress.com/2010...olean-harmful/

>
> +1
>
> This might irritate those who already find Java verbose, since 'String's
> are more compact to declare, but type safety and refactorability [sic]
> is a payoff in many situations.
>
> I'm even worse, because I pump a "friendly" string representation into
> the enum.
> <http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html#toString()>
> «An enum type should override this method when a more
> "programmer-friendly" string form exists.»

I'm even worse than that. My designs often include replacing a boolean
with an Enum that has *logic* in it. Flyweight strategy pattern.

public enum FooStrategy {
ONE_WAY {
public void handle(Foo foo) {
foo.doItOneWay();
}
},

ANOTHER {
public void handle(Foo foo) {
foo.doItAnother();
}
}
;
public abstract void handle(Foo foo);
}

This is more verbose but ends up being more flexible and easier to
maintain. Enums can even implement interfaces, so you could add
additional layer of abstraction which allows custom or statefull
implementations alongside the the enum implementations.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Having compilation error: no match for call to (const __gnu_cxx::hash<long long int>) (const long long int&) veryhotsausage C++ 1 07-04-2008 05:41 PM
Use of Long and Long Long Bart C C Programming 27 01-15-2008 05:27 AM
long long and long Mathieu Dutour C Programming 4 07-24-2007 11:15 AM
unsigned long long int to long double Daniel Rudy C Programming 5 09-20-2005 02:37 AM
Assigning unsigned long to unsigned long long George Marsaglia C Programming 1 07-08-2003 05:16 PM



Advertisments