* Re: Contrained ada type in java
2003-12-11 3:56 ` David C. Hoos, Sr.
@ 2003-12-11 17:56 ` Jeffrey Carter
2003-12-17 5:56 ` Craig Carey
1 sibling, 0 replies; 5+ messages in thread
From: Jeffrey Carter @ 2003-12-11 17:56 UTC (permalink / raw)
> "Ed Trubia" <edward.b.trubia@lmco.com> wrote:
>> type ET_ACTIVE_PORT_CONFIGURATION is
>> ( HDX_TX1_RX1,
>> HDX_TX2_RX2,
>> HDX_TX1_RX2,
>> HDX_TX2_RX1,
>> FDX_TX1_RX2,
>> FDX_TX2_RX1);
>>
>> for ET_ACTIVE_PORT_CONFIGURATION use
>> ( HDX_TX1_RX1 => 62,
>> HDX_TX2_RX2 => 23,
>> HDX_TX1_RX2 => 34,
>> HDX_TX2_RX1 => 45,
>> FDX_TX1_RX2 => 54,
>> FDX_TX2_RX1 => 61);
Since this won't compile (the enumeration values must be monotonically
increasing), it should be impossible to implement in Java.
--
Jeff Carter
"Sir Lancelot saves Sir Gallahad from almost certain temptation."
Monty Python & the Holy Grail
69
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Contrained ada type in java
2003-12-11 3:56 ` David C. Hoos, Sr.
2003-12-11 17:56 ` Jeffrey Carter
@ 2003-12-17 5:56 ` Craig Carey
2003-12-17 14:54 ` No Spam
1 sibling, 1 reply; 5+ messages in thread
From: Craig Carey @ 2003-12-17 5:56 UTC (permalink / raw)
On Wed, 10 Dec 2003 21:56:10 -0600, "David C. Hoos, Sr."
<david.c.hoos.sr@ada95.com> wrote:
>This is an enumerated type, a feature of many
>languages, but not of Java.
>
>There are a number of ways to deal with this in Java
>
>See the following web site for some suggestions:
>http://gethelp.devx.com/techtips/java_pro/10MinuteSolutions/10min0600.asp
>
>Of course, the best solution is to leave the program in Ada!
>
Mr Trubia explained in an earlier message that Ada was being ported to
Java. It seems suspect. What is the private company, Lockheed Martin,
up to ?.
Is Lockheed going to produce an Ada to Java parser.
I used the search engine at the Lockheen Martin website and it seemed to
identify only the US Navy (subsea machines) as producing the interest in
Java.
Ada allows this: "type e1 is (a, b, c); type e2 is (a, b, d);", etc.
Here is the ...["dogfood Sun won't eat"] version
| Now we can guarantee that a Stereo instance can only have a Volume
| equal to one of the discrete levels we have defined (and null). The
| problem with this approach is that now we have lost the ordering of
| the values. We also can no longer manipulate the values as integers,
| disallowing their use in a switch statement. A natural addition
| would be to add a member variable to Volume defining the ordering of
| the levels as follows:
|
| public final class Volume implements Comparable {
| public static final int SILENT_LEVEL = 0;
| public static final int SOFT_LEVEL = 1;
| public static final int AUDIBLE_LEVEL = 2;
| public static final int LOUD_LEVEL = 3;
| public static final int ELEVEN_LEVEL = 4;
|
| public static final Volume SILENT = new Volume(SILENT_LEVEL);
| public static final Volume SOFT = new Volume(SOFT_LEVEL);
| public static final Volume AUDIBLE = new Volume(AUDIBLE_LEVEL);
| public static final Volume LOUD = new Volume(LOUD_LEVEL);
| public static final Volume ELEVEN = new Volume(ELEVEN_LEVEL);
|
| private static final Volume __VOLUMES[] = {
| SILENT, SOFT, AUDIBLE, LOUD, ELEVEN
| };
|
| private int __level;
|
| public static final Volume getVolume(int level) {
| if(level >= SILENT_LEVEL && level <= ELEVEN_LEVEL)
| return __VOLUMES[level];
| return null;
| }
|
| private Volume(int level) {
| __level = level;
| }
|
| public boolean equals(Object obj) {
| // Assume proper type was given
| return (__level == ((Volume)obj).__level);
| }
|
| public int compareTo(Object obj) {
| // Assume proper type was given
| int other = ((Volume)obj).__level;
| if(__level == other)
| return 0;
| if(__level < other)
| return -1;
| return 1;
| }
|
| public int getLevel() { return __level; }
| }
|
| This solves the ordering problem and the manipulation of the values
| as integers. You can determine ordering with equals() and
| compareTo(). And if you want to use the values in a switch
| statement, you can fetch a value to test with getLevel() and use the
| LEVEL constants as the cases. You may be wondering why we added the
| getVolume() factory method. If we omit the factory method, a small
| problem arises with respect to serialization. The Volume class has a
| private constructor and no setter methods so that we may limit the
| range of values it can represent. This also makes it unserializable.
| A serializable class must declare Volume variables as transient, and
| manually store the getLevel() value. On deserialization, the class
| may recreate its Volume member by using the getVolume() factory
| method. A benefit of this approach is that it allows you to continue
| to use the == operator for comparison operations, rather than
| restrict you to invoking equals(). Another way to deal with
| serialization to create a readRsolve() method like the following:
|
| private Object readResolve() throws ObjectStreamException {
| return __VOLUMES[__level];
| }
|
| This prevents duplicate constants from being created during
| deserialization.
|
| It is quite a lot of work just to get the functionality of
| enumerated types. Simply using integer constants will be sufficient
| for most programs, but when value restriction and type safety become
| issues, you will have to resort to some variation of the more
| complicated solution.
|
If the Navy is Java enthusiast then they must have rules that
prevent a rational approach that leads to:
(a) a quality (no murky Sun bugs) implies that a 3GL be used
(b) the existing 3GL is Ada so that would be embedded
(c) most of the existing Ada is left unchanged and what was required
to be a Java project is best implemented with Java being a bindings
shell.
It might be some document requestable under US FOI laws. Still the
Navy is unsoundly identified. Now that Mr Ed Trubia is sending in
multiple messages on Java, I hope he can name the documents that could
be requested under FOI provisions.
Craig Carey
^ permalink raw reply [flat|nested] 5+ messages in thread