Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Function overloading #20

Open
MeAmAnUsername opened this issue Jun 25, 2020 · 0 comments
Open

Function overloading #20

MeAmAnUsername opened this issue Jun 25, 2020 · 0 comments
Labels
Component: DSL Something that concerns the design of PIE DSL Priority: low Status: proposal Enhancement in the proposal stage Type: enhancement New feature or request

Comments

@MeAmAnUsername
Copy link
Owner

MeAmAnUsername commented Jun 25, 2020

Allow overloading functions, i.e. have functions with the same names

code generation

  1. no code generation, all functions with less parameters get desugared to calls with default parameters
  2. generate to same task. May be possible by creating an abstract Input class that has subtypes for the possible input types. Could apply strategy pattern in subclasses to implement different behavior for each input type.
class someTask implements TaskDef<someTask.Input, Output> {
  <I extends Input<I>> private static interface Input<I> extends Serializable {
    // private so that other classes can't implement this and provide something else
    // can be made public?
    Output exec(ExecContext context, I input);
  }

  public static class Input1 extends TupleX implements someTask.Input<someTask.Input1> {
    public Input1(...args...) {
      ... assign fields ...
    }
    
    public Output exec(ExecContext context, Input1 input) { ... }
  }
  
  public exec(ExecContext context, Input input) {
    return input.exec(context, input);
  }
}
  1. generate to different tasks. Each task takes only one input and has a distinct name.

Options

Easy: default parameters

last parameters can have defaults. Generate functions that pass the default values.
Code generation: 1, 2 or 3.

Medium: user-defined implementation, one function per arity

allow each overload to have its own implementation. Each function combined with its number of parameters must be unique.
Code generation: 2 or 3

Hard: user defined implementations, arbitrary overloads

Allow arbitrary overloads. They are basically completely separate functions except that they have the same name.
Requires some way to choose which function to use when they have the same arity. Use most specific signature? Follows Java semantics, but don't know if that works in NaBL2.
Code generation: 2 or 3

@MeAmAnUsername MeAmAnUsername added Type: enhancement New feature or request Status: proposal Enhancement in the proposal stage Component: DSL Something that concerns the design of PIE DSL Priority: low labels Jun 25, 2020
MeAmAnUsername added a commit that referenced this issue Jun 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: DSL Something that concerns the design of PIE DSL Priority: low Status: proposal Enhancement in the proposal stage Type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant