Structs should be separed by namespaces

[yfarjoun]

When importing a wdl (B) that has a Struct definition into another wdl (A), one can use and reference that struct in A without needing to note the namespace of the Struct. This has two negative implications:

1. There could be name clashes when two imports define a Struct with the same name.
2. It is harder to read the code as it isn't clear what import needs to be examined in order to find the WDL (and it can be several layers down)

I would propose forcing the user to decorate the structure with the name of the imported library before using an imported structure.

problem that needs to be solved: What to do when the same structure is effectively imported twice, once directly, and once via a third wdl? will the parser know that it's the same? should the user be forced to import the struct directly and only use that?

[patmagee]

I agree that this or something similar is certainly needed. Originally I avoided this to prevent type declarations like the following, which seemed burdensome at the time.

sub.Person p 

Instead I opted for an alias method. this obviously works when imported workflows are well known, but adds a bit of extra boilerplate if there are alot of conflicting structs.

import http://example.com/another_exampl.wdl as ex2
    alias Parent as Parent2
    alias Child as Child2
    alias GrandChild as GrandChild2

I am not sure what the right answer is here, as I have not run into this case myself yet.

[yfarjoun]

I think that both are reasonable, and I'd like to have both if possible.

[mlin]

Tangential question I just wanted to write down here. The spec does not clearly forbid name collisions between values and calls in a workflow (i.e. I can have Int x and call tsk as x in the same workflow - true?). This is mostly ok because there's usually no contextual ambiguity about which one is meant (you don't put a call where a value is expected and vice versa). This breaks down with struct member access though, if the struct field has the same name as a task output. Possibly this is already broken with pairs and left/right access.

From a spec perspective, do we forbid all value/call name collisions or only those involving structs/pairs or only those where actual ambiguity could exist or only those where ambiguity does exist?

[DavyCats]

Just to keep things simple for the user, I would say forbidding any and all name collisions would be preferable.