I'm wondering if Fantom supports a shorthand syntax to achieve structural equality on objects? For instance, this is the Fantom code I came up with for a class with two integers:

const class Foo {
  const Int x;
  const Int y;

  new make(Int x, Int y) {
    this.x = x;
    this.y = y;
  }

  override Bool equals(Obj? other) {
    if (other isnot Foo) return false;
    Foo foo := other;
    return x == foo.x && y == foo.y;
  }
  override Int hash() {
    return x * 13 + y * 137;
  }
}

Here is the corresponding Scala code:

case class Foo(x: Int, y: Int)

The Fantom code is too much of a showstopper for me, even if my IDE can generate make, equals, hash.

In my case, Fantom could very well replace Scala if it supported a shorthand for structural equality (like the case class in Scala).

Did I miss some feature of Fantom that makes this easier? Or does the Fantom community not consider this to be a problem?

I've always thought that Fantom is way too verbose here. See topics 1135 and 378.

I think it is considered a problem and there has been much discussion on a potential solution, but no final design yet.

I had an idea as some kind of DSL annotation. For examples

@Auto
const class Foo { Int x; Int y;}

would generate OP example. I haven't yet started implementing this thing (lots of other stuff to work on), but it should be feasible with DSL plugins in Fantom, right?

@DanielFath: The Pojomatic project for Java has sort of similar conventions.

There is an @AutoProperty annotation which you can apply on the class level to include all properties. Alternatively, you can supply a @Property annotation on each property, optionally specifying whether the attribute is included in equals, hashCode and/or toString.

Personally I would rather this implemented through a library and a mixin, rather than with DSL magic. I can inspect a library's source code to see what it does--I can't always predict what a DSL plugin will do to my code.

@DanielFath @qualidafial

Project Lombok is an interesting implementation for Java of exactly the idea that qualidafial describes:

http://projectlombok.org

Unfortunately it works by plugging into non-public compiler API:s and generating methods on the annotated objects, i.e. magic.

Thanks for the replies.

A compile-time solution would have been nice since reflection is too slow for my needs. When you do tons of map and set operations, equals/hash can easily become a bottleneck.

@Jens: Thanks for that link. I doubt I'll ever use it, but it did shatter my world-view of what you can and cannot do by simply putting a .jar on your classpath.

@asf

simply putting a .jar on your classpath.

With Lombok they actually do a bit more. It has to plug into the compiler. Im not sure if it does this by the normal annotation processor mechanism, or if they hack into some private parts of the compiler, but for it to work they use non-public, implementation dependent parts of the compiler to emit code into annotated classes.