Allow undefined/null value for INPUT_AUTO and OUTPUT_AUTO

[daniels]

I suggest that the specification should allow null values for INPUT_AUTO and OUTPUT_AUTO, and that the constructors should not be required to check for the empty string if a null value can be used instead.

In languages where the empty string is not "falsy" (in my case Ruby) it makes for a cleaner implementation to not have to check for it but instead rely on the truthiness of the parameter. It isn't much extra code that is needed to do the check, but using common idioms of the implementation language makes the intent more clear.

[WasabiFan]

Are you saying that the constants *_AUTO should have the value of null? Or are you saying that blank strings should not be allowed (or only processed if the falue isn't falsey)?

[daniels]

I'm not really sure... :-)

I guess I'm saying that an implementor should be allowed to use null as the value of the *_AUTO constants, and iff the implementor chose to do that not be required to check for the empty string in the constructors. For some languages using an empty string still would make sense, so I'm not arguing against allowing that too.

It would probably be harder to explain in the table though.

As I'm not sure exactly what problem the specification is trying to solve, maybe this isn't in line with your ambitions. But seen as a lowest common denominator I hope that the spec won't push implementors away from good practice and idiomatic use of their language.

[fdetro]

IMHO the specification should only enforce the existence of the AUTO port constants, and should allow default constructors without specifying a port (if possible in the language). Whether the AUTO constants are implemented as null or empty string is language / implementation dependent.

[WasabiFan]

Good idea; I think that will be better than specifying the value as we do now. I'll make that adjustment shortly.

[WasabiFan]

This has been added to the specification.