https://git.opendaylight.org/gerrit/#/c/53363/ has a one of manual related thing (for Uuid); if this was available, that code would have to make a little bit less of a hand-stand to recreate Pattern from String.
> public static final Pattern[] PATTERNS;
Do you mean this?
public Pattern[] getPatterns()
{ return Arrays.copyOf(patterns, patterns.length); }> Do you mean this?
yes, otherwise it's mutable (even if final, the array elements could be changed, which we certainly wouldn't want...) so yeah that is what actually I meant... thanks! 
actually on further thought, having to Arrays.copyOf() for every time you getPatterns() isn't ideal, if it can be avoided, so it would be better to just offer something like:
public static final List<Pattern> PATTERNS = ImmutableList.of(PATTERN_CONSTANTS.transform(...));
This is more consistent with the existing PATTERN_CONSTANTS. Or, if a method like getPatterns(), then it should be "static" (above it is not). But having a public field for the String pattern but a static getter for the regexp Pattern object isn't consistent.
I do not quite get the use case. Why do you need to programmatically access the pattern?
Also details how the value validity is enforced is an implementation-private detail, which can change at any time and we certainly do not want application code to be tied to that.
More specifically, the pattern strings exposed are the strings coming from the model and are useful for reporting. They are not guaranteed to pass Pattern.compile() – they just happen to do so because YANGTOOLS-587 was left unaddressed for a long time. Now that has happened, PATTERN_CONSTANTS will actually contain raw patterns and an internal constant will carry the strings for enforcement.
> Why do you need to programmatically access the pattern?
to be able to check whether a String matches the pattern, as in https://git.opendaylight.org/gerrit/#/c/53363/ (originally motivated out of code in https://git.opendaylight.org/gerrit/#/c/53118/ for NETVIRT-514).
> details how the value validity is enforced is an implementation-private
> More specifically, the pattern strings exposed are the strings coming
> from the model and are useful for reporting. They are
> not guaranteed to pass Pattern.compile()
OK, all the more reason then to offer a better API than just exposing String?
What would also work here, instead of exposing a Pattern instance as originally suggested, and may be better, is to just directly offer a method with a signature like:
public static boolean matches(CharSequence input)
because this is what I want to have access to the pattern for anyway - and I can't think of anything else one would want to do with a Pattern, anyway. (PS: Going this way may also prevent stupid API users from making a concurrency mistake; Pattern is thread safe, Matcher is not - just having a matches() takes away any possible room for misuse of this.)
Or just completely forget about this and only do MDSAL-239? Although I think both have potential uses (and an implementation of MDSAL-239 could be built upon a matches(), as could those generated constructors which, currently, internally do pattern.matcher(_value).matches()).
If the intent is to create a binding object when the argument matches, the only reliable solution is [2]. For example the string subtype can have length constraints aside of patterns.
Michael, I don't want to sound negative, but what kind of business logic relies on external constraints (defined by the model) to decide what class of object to instantiate?
I mean this sounds like you really want to be instatianting a union of some kind, rather than having a clearly-defined model – if you have a fallback type which is more general than UUID, why not use that?
> what kind of business logic relies on external constraints
> (defined by the model) to decide what class of object to instantiate?
> sounds like you really want to be instatianting a union of some kind,
> rather than having a clearly-defined model – if you have a fallback
> type which is more general than UUID, why not use that?
well in the case of how they solved NETVIRT-514 in c/53118, it actually does not even instantiate either this or that, it's just a dumb "if it's that then do this, else do nothing" check. I'm not yet familiar enough with the details of the netvirt model and that code to be able to judge if this really is more an indication of some sort of underlying design flaw which, in an ideal world, should be conceptually addressed more globally, by a new union YANG type on that model, or otherwise - you may well be perfectly right that it is! This issue was merely created out of the realization of an existing case where it was handled by checking the constraint explicitly.
As stated in MDSAL-239 I won't loose sleep over if we just close this and forget about it.
> you really want to be instatianting a union of some kind
Exactly. I see benefits of recognizing specific types (perhaps the input is from some less strongly typed protocol), but unions (as opposed to ad-hoc Java binding enhancements) are there exactly for that kind of data.
> in an ideal world, should be conceptually addressed more globally,
> by a new union YANG type on that model, or otherwise
You can create my-internal-maybe-uuid-union.yang in your sub-project to hold the typedef for your implementation to use, without affecting anyone else (perhaps after asking upstream projects if they wish to host that first).