Allow runtime attribute values via static methods

[ohadschn]

Attribute values are limited to compile-time constant attribute parameter types. This can be limiting when values need to be evaluated at runtime. For example, I might want to take my help text or license from some file, or I might want a non-constant default value, or I might want dynamic options, etc.

One way around this would be a string pointer to a property/method which would supply the actual value:

class MyOptions
{
    [Option('f', "foo", HelpTextProperty = nameof(FooHelpText), Default = nameof(FooDefault))]
    public int Foo {get; set;}

    private string FooHelpText {get { return File.ReadAllText("foo.txt"); } }
    private int FooDefault {get { return Math.Pow(2,5); } }
}

Of course type validation would be performed (Default should have an assignable type to the property type, HelpTest should be a string, etc) for all such pointers (regardless of whether they are actually invoked, to fail fast in case of type inconsistency)

This is just one example, I believe this could be useful for many other attribute properties. To explicitly name the attributes currently defined in the library:

• AssemblyLicenseAttribute (don't really understand the multiple line thing BTW, why not just pass the full string including newlines)
• AssemblyUsageAttribute (same comment)
• OptionAttribute
• ValueAttribute
• UsageAttribute
• VerbAttribute

[ericnewton76]

I've been considering a fluent interface for something similar:

program
  .option("--defaultFileName", "Web.config")
  .option("--file", null, () => { FileStream.OpenText(program.values.defaultFileName) })
  .option("--stdin", null, () => { return Process.StdIn; })
  .parse(args)

still working out the interface

[ohadschn]

@ericnewton76 that sounds cool but I think my proposal would still have its place, as it is more consistent with the attribute decoration style. If I only have one non-constant attribute property, it would be a shame to forego the declarative attribute model.

Combining the methods would be a possibility (some flags with .Option and some with OptionAttribute) but I don't like it very much as it is inconsistent and potentially confusing (you think you know where the flags are defined, but some of them are actually defined somewhere else in a different manner).

[moh-hassan]

PR is welcome