Java interfaces for common behavior (with Ruby as a possibility too)

[enebo]

Four regexp nodes (e.g RegularExpressionNode, InterpolatedRegularExpressionNode, ...) have the same set of isIgnoreCase regexp flag methods to evaluate RegularExpressionFlags). There are some other common things we do like getName() across several node types where we can share common logic due to the node having an interface attached. It would be nice to attach these subsets of behavior to nodes. Look at the contracts field below:

  - name: RegularExpressionNode
    fields:
      - name: flags
        type: flags
        kind: RegularExpressionFlags
      - name: opening_loc
        type: location
      - name: content_loc
        type: location
      - name: closing_loc
        type: location
      - name: unescaped
        type: string
      - contracts: [RegularExpressionFlagsContract]
    comment: |
      Represents a regular expression literal with no interpolation.

          /foo/i
          ^^^^^^

I picked names and I don't want to bike shed on that at the moment so let's consider the idea more first. In this case, RegularExpressionFlagsContract would have a pre-made Java interface which contains all the signatures associated with examining flags. The generator for Nodes would just add implements for each contract. Without something like this we are in the position if we want to call these methods we need four independent piece of code (since we have 4 regexp types with flags).

The added possible bonus here is this could be useful for Ruby as well. At a minimum we could make empty marker modules so we could flag things as performing calls (e.g. node.kind_of? PerformsCallContract). Markers would decouple some of the need to try and keep things are one combined node when more smaller nodes would work. The other possibility here is it could make some rbs or sorbet sorts of typing systems with richer information.

I should add I realize for regexp we could just add that interface manually just in the Java side of things but I like being able to read config.yml and I like the notion this could be more useful than some hard-coded Java. Having said that if this has no value being in config.yml we will just likely only fix this in Java generated code.

[kddnewton]

Yeah this makes a lot of sense. The only thing I think I would change is to have a top-level contracts key that lists each one, and then lists the various fields. That way we could generate code in the same way and just mark everything as abstract.

Also this would be useful for the rust binding; this would be traits.

[enebo]

If this is reasonable we should probably bike shed a little then 😄 A first attempt will be for regexp flag processing since it is very repetitive codewise.

[eregon]

Note that for RegularExpressionFlags (and other flags) there is already a corresponding generated Java class, this is very useful to avoid duplication and already used in TruffleRuby YARPTranslator.

[eregon]

https://github.com/oracle/truffleruby/blob/5a199d82ea4436930a07ce747802c445d071db1a/src/main/java/org/truffleruby/parser/YARPTranslator.java#L1554

[enebo]

Oh!!!! I don't like your solution but once I read it I thought, "why don't we have static methods for this so we don't need to alloc an object just to process an int?". You added static methods for this! I can just rewrite all four nodes using those.

[eregon]

Yeah safer typing vs no allocation, I figured out both might be wanted so that class provides both, glad to see you can use it too :)

[kddnewton]

My only thing is I think I'd prefer to call them "interfaces" rather than "contracts"

[eregon]

Do we anticipate multiple contracts/interfaces per node? I think it's unlikely.
If not we could instead use an abstract superclass which contains the common fields and methods.
That would be a lot more efficient and also keep it possible to access fields with just the field notation rather than through virtual methods (in Java at least but not only).

[eregon]

Another thought/note related to this is we could also use it for *TargetNode and the corresponding non-target variant since they share most fields except the value.

[enebo]

@eregon The contract for any template which uses them could decide to pick what works best. We can choose whether abstract superclass fits best or whether interface does.

[eregon]

Indeed. Although of course if we want to leave the possibility to use a superclass then it can only be at most one contract per node type, because e.g. Ruby/Java/etc classes can only have one superclass.
Also with #2092 (comment) it feels natural to specify it like "superclass fields", and then let languages use a superclass ("supertype") or trait or decide to flatten in leaf classes as makes more sense.

For Java I think a superclass is by a wide margin better than interfaces, performance-wise and more natural to access common fields.
For Ruby that's likely less clear already, and arguably Ruby might not even need anything thanks to duck-typing.