This is a bug and a feature request, I guess.
The bug is, I am beginning a port of one of my more mature and oft-used C# classes, TextFileReader. The C# constructor has sort of grown like Topsy and its signature now looks like this:
Reproducing this in Objo, the char delimiterCharacter becomes a string of length one:
... Optional delimiter as String = ",", Optional encoding As TextEncoding = TextEncoding.UTF8, ...
Somewhere during editing this changed itself to:
Optional delimiter as String = ", ", Optional encoding As TextEncoding = TextEncoding.UTF8, ...
I removed that extra space in the default string literal and now, coming back from lunch, I notice that it's wrong again.
That's the bug. I suspect it may be specific to the string containing a comma getting confused with the comma separating this from the next argument.
The feature suggestion is this. Along with all these Optional arguments comes this warning: "Constructor has 8 parameters; consider grouping related values."
Well there are basically 3 ways to handle this in most languages:
1) Skippable optional arguments. For example if I wanted to take all the defaults and just change the last one:
new TextFileReader(path, name ,,,,,true);
2) Positional arguments:
new TextFileReader(path, name, @permitEmbeddedLFCR = True);
3) Wrap all the optional arguments in a TextFileReaderSettings class, make that an Optional argument of type TextFileReaderSettings which defaults to just a default instance with all the default values. Then do something like:
var tfrOptions = new TextFileReaderOptions();
tfrOptions.PermitEmbeddedLFCR = true; // or use positional args to the options constructor
var tf = new TextFileReader(path, name, tfrOptions);
OR:
var tf = new TextFileReader(path,name,new TextFileReaderOptions {PermitEmbeddedLFCR = True});
I believe you can also just expose the settings as public properties of the main class and use setter injection, e.g.:
var tf = new TextFileReader(path,name,{PermitEmbeddedLFCR = True});
All of these options have tradeoffs -- developer preference / readability, verbosity, even security.
If Objo has any of these other options (apart from using a separately instantiated class wrapper to pass multiple arguments), I probably don't know where to find them in the docs because Objo uses different terminology than what I'm accustomed to.
Philosophically speaking, Objo could decide to be opinionated and limit us to a separately instantiated settings / context / helper class for "grouping arguments" so as not to baffle noobs with too many options. Or it could take more the MSFT approach which is to let devs decide what they are most comfortable with or prefer in certain contexts. I lean in the latter direction, particularly when these more arcane syntax options don't have to be learned in advance to do useful work; rather, they are just there to discover as you mature in the craft.