I mean, what better way to discourage usage than if users don't even know it exists!? Of course, the reason for keeping the old method is to retain backwards compatibility with older and / or 3rd party code.
So I was wondering if @NoDoc could be taken into account when printing usage details for @Opt fields?
using util
class Main : AbstractMain {
@Opt { help="Now you see me..." }
Str? foo
@NoDoc @Opt { help="Now you don't" }
Str? bar
override Int run() { ... }
}
C:\> fan acme -help
Usage:
Main [options]
Options:
-help, -? Print usage help
-foo <Str> Now you see me...
That way if you wanted to rename, upgrade or simply hide an option, you could - whilst keeping the old functionality hanging around.
I guess usage is limited as you could just augment the help text with (Deprecated), but it may be nice to be able to add undocumented features.
SlimerDude Sat 6 Feb 2016
@NoDoc
is an awesome little feature. One of my favourite tricks is to use it in conjunction with@Deprecated
.I mean, what better way to discourage usage than if users don't even know it exists!? Of course, the reason for keeping the old method is to retain backwards compatibility with older and / or 3rd party code.
So I was wondering if
@NoDoc
could be taken into account when printingusage
details for@Opt
fields?That way if you wanted to rename, upgrade or simply hide an option, you could - whilst keeping the old functionality hanging around.
I guess usage is limited as you could just augment the help text with
(Deprecated)
, but it may be nice to be able to add undocumented features.brian Mon 8 Feb 2016
I like that idea, I pushed a fix