I ran into it like this:
Code:
record AdventureResult
{
item it;
int count;
};
static AdventureResult NO_RESULT = new AdventureResult( NO_ITEM, 0);
...
// Campground item corresponding to garden type
AdventureResult garden_seeds = NO_RESULT;
...
void parse_garden()
{
...
garden_seeds = new AdventureResult(it, n);
...
}
...
parse_garden();
if (garden_seeds == NO_RESULT) {
print( "You don't have a garden in your campground." );
return;
}
And was really confused when it successfuly parsed the garden type and still printed the error.
I worked around, for now, like this:
Code:
if (garden_seeds.it == NO_RESULT.it) {
Initial musing:
Value implements Comparable.
CompositeValue extends Value and therefore implements Comparable.
But, as coded, composites do not have a natural ordering.
I would think that we COULD implement equals, but not compareTo.
At the least, compareTo should throw a ClassCastException if the Type of the two objects is not identical.
Stepping back, "==" and "!= " should be allowed for any ASH values.
Perhaps for Composites, it should boil down to Object equality. I.e. if the two Value objects are == in Java.
We COULD do deep comparison, but that's a can of worms.
For example, since the contents are mutable, hashCode must not be allowed to change if the contents change.
(Does that matter, in practice? I don't think we allow composite values to be keys in ASH maps.)
Operator.compareTo should call equals(), not compareTo(), for "==" and "!= operators.
Parser should disallow "<", "<=", etc. for non-simple Types.
CompositeValue and/or RecordValue could override equals() and we could decide if we really want deep comparison.
In any case, equality (and comparison) should presumably require the same Type of objects?
"record a" and "record b" objects are always unequal .
Operator coerces left and right values to have comparable types before comparing them.
Composite values are not coercable.
Initial observations; I haven't decided yet how I think this all work.
Making Operator.compareTo call equals() for "==" and "!-", overriding CompositeValue.equals to use Object equality, and doing whatever has to happen in between, would suffice to fix my initial issue. But I want to consider the bigger picture and decide what else could/should be done.