INV Best practices

Only one INV object per file

To avoid more complexity, you should always keep yourself to 1 INV object.

Ok:

inv {
   name 'my-inv'
}

Not ok:

inv {
    name 'my-inv'
}
inv {
    name 'my-second-inv'
}#### Only one INV object per file
To avoid more complexity, you should always keep yourself to 1 INV object.

 
 ```groovy
// Ok
inv {
    name 'my-inv'
}

// Not ok
inv {
    name 'my-inv'
}
inv {
    name 'my-second-inv'
}

Use 'need' and 'publish' suffix for delegated broadcast and require statements

It may seem strange, but an arbitrary convention is better than no convention. Delegated (or shared) statements are a necessity for a complete ecosystem, but they are more difficult to maintain than a regular statement. You will need some kind of visual trait to determine whether a closure is bound to the callee settings.

By convention,

• To delegate a broadcast statement, add the 'publish' suffix to your closure/method;
• To delegate a require statement, add the 'need' suffix to your closure/method.

The suffixes 'require' and 'broadcast' are not not recommended since it is harder for consumers to guess who will eventually owns the statements.

// Ok
inv {
    ...
    broadcast { Something } using {
        ready {[
            publishElse: {
                broadcast { Else }
            }           
        ]}   
    }
}

//Not ok
inv {
    ...
    broadcast { Something } using {
        ready {[
            getElse: {
                broadcast { Else }
            }           
        ]}   
    }
}

// Ok
inv {
    ...
    broadcast { Something } using {
        ready {[
            needElse: {
                require { Else }
            }           
        ]}   
    }
}

// Not ok
inv {
    ...
    broadcast { Something } using {
        ready {[
            requireElse: {
                require { Else }
            }           
        ]}   
    }
}

Use 'need' and 'publish' suffix for delegated (or shared) broadcast and require statement

It may seem strange, but an arbitrary convention is better than no convention. Delegated (or shared) statements are a necessity for a complete ecosystem, but they are more difficult to maintain than a regular statement. You will need some kind of visual trait to determine whether or not a closure is bound to the callee settings.

By convention,
when you wish to broadcast something, add the 'publish' suffix to your closure/method. when you wish to require something, add the 'need' suffix to your closure/method.

Suffixes 'require' and 'broadcast' are not recommended to distinguish more easily owned statements against delegated statements.

Broadcast

Ok:

inv {
    ...
    broadcast { Something } using {
        ready {[
            publishElse: {
                broadcast { Else }
            }           
        ]}   
    }
}

Not ok:

inv {
    ...
    broadcast { Something } using {
        ready {[
            getElse: {
                broadcast { Else }
            }           
        ]}   
    }
}

Require

Ok:

inv {
    ...
    broadcast { Something } using {
        ready {[
            needElse: {
                require { Else }
            }           
        ]}   
    }
}

Not ok:

inv {
    ...
    broadcast { Something } using {
        ready {[
            requireElse: {
                require { Else }
            }           
        ]}   
    }
}