GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Add support for keyword-style arguments · Issue #245 · scijava/scijava

Add support for keyword-style arguments #245

New issue
Copy link
New issue
Copy link
Open
Open
Add support for keyword-style arguments#245
Copy link
Milestone
unscheduled

Description

@ctrueden
ctrueden
opened on Jul 29, 2024
Issue body actions

Some programming languages (e.g. Python) have support for keyword arguments, in addition to only ordered arguments. Furthermore, in Python at least, one can have a function with keyword only arguments, which can happen if an argument follows the varargs *args syntax, or in general for the **kwargs syntax. In either situation, the name of the parameter must be given along with the intended value.

SciJava Ops currently does not have a feature like this, but it could. Here is one possible syntax:

Img image = ...;
double sigma = ...;
Img result = ...;
Computers.Arity2<Img, Double, Img> gaussOp =
ops.op("filter.gauss")
    .input("image", image)
    .input("sigma", sigma)
    .output(result)
    .computer();

In the example above, the image and sigma parameters are individually given by separate .input(name, value) calls. A big advantage of this design is that it preserves the type safety offered by Ops. A downside is that the OpBuilder infrastructure would need to expand a lot to accommodate it. Another difficulty is that the op matching engine is currently fully built around the idea of ordered parameters, and it would need refactoring to support op requests with unordered+named inputs. But all of that could certainly be done with effort.

This goal of supporting op matching by named inputs would make it more elegant to wrap such Python functions into Ops. But even with it in place, Ops does not support varargs and might never do so, since it weakens type safety.

Activity

  1. ctrueden
    added this to the unscheduled milestone on Jul 29, 2024
  2. gselzer
    added this to SciJava Ops Paper #2: Polygloton Jul 31, 2024
  3. gselzer commented on Jul 31, 2024

    @gselzer
    gselzer
    on Jul 31, 2024
    Member
    More actions

    I appreciate your solution, however for completeness I'll write down another solution - simply treat keyword-only arguments as positional arguments. At the end of the day, we'll need Python-based OpInfo objects that will have to know how to make Ops capable of calling Python code - they could give the impression of required positional arguments that get permuted into keyword-only arguments. The main benefit of this course of action is no additional API, and no changes to the matcher. This may be a good first attempt targeted for minimal effort and refactored later if insufficient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    • SciJava Ops Paper #2: Polyglot
      Status
      No status
      Show more project fields

    Milestone

    • unscheduledNo due date

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    You are visitor 01402503 — GeezerVison does not store the pages you look up.
    Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.