myGrid

t2 should support implicit iteration in input port

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: By Design
  • Affects Version/s: None
  • Fix Version/s: 1.7.1
  • Component/s: t2 maelstrom
  • Description:
    Hide

    Perhaps a discussion point, but it is my view that users do currently (in t1) use the possibility to immediately change a workflow to do implicit iteration on its input ports by providing more than one value, even if the first services in the list expects a single value.

    t2 does not support this and is stricter on that the input value needs to match the input port's depth (which again has to match to the depth of the next service, since there is no way in t1 to specify the depth on an input port directly).

    This could easily be achieved by wrapping the translated t1-workflow in a nested workflow. For core t2 workflows we probably want to keep the current strict rule.

    Show
    Perhaps a discussion point, but it is my view that users do currently (in t1) use the possibility to immediately change a workflow to do implicit iteration on its input ports by providing more than one value, even if the first services in the list expects a single value. t2 does not support this and is stricter on that the input value needs to match the input port's depth (which again has to match to the depth of the next service, since there is no way in t1 to specify the depth on an input port directly). This could easily be achieved by wrapping the translated t1-workflow in a nested workflow. For core t2 workflows we probably want to keep the current strict rule.

Activity

Hide
Tom Oinn added a comment - 2008-01-29 12:20

This is intentional - the type checker needs to have a definite base type for its inputs to be effective. It would be possible to create a UI over this that detected the type the user had specified and modified the input types, ran the checker etc. but the basic functionality is correct this way.

Show
Tom Oinn added a comment - 2008-01-29 12:20 This is intentional - the type checker needs to have a definite base type for its inputs to be effective. It would be possible to create a UI over this that detected the type the user had specified and modified the input types, ran the checker etc. but the basic functionality is correct this way.

People

Dates

  • Created:
    2007-12-06 17:37
    Updated:
    2008-01-29 12:20
    Resolved:
    2008-01-29 12:20