Pattern method names based on existing library conventions [was Re: Pattern matching for nested List with additional size constraints]

[Stephen Colebourne]

On Thu, 28 Jan 2021 at 16:42, Brian Goetz <brian.goetz at oracle.com> wrote:
> if a class has _only_ one name of factory method (make, newFoo), I think
> the idiom of "deconstruct those with a deconstructor" might be a
> reasonable option, because deconstructors don't need this degree of
> flexibility, and the name chosen by the API designer isn't really adding
> any value, since they're all the same.

The Optional class is weird here. Reading this again, I agree that the
"empty" name is important. But the "of" name is noise. Because I think
Optional is really very record-like.

  switch (opt) {
    case Optional(var v) ...
    case Optional.empty() ...
  }

I understand the shudder from the inconsistency, but I think this is
actually fully consistent.

The criteria for "deconstruct with a deconstructor" should be whether
the class has a single standard internal state that it fully exposes,
just like a record would. If this rule were widely adopted then the
apparent Optional inconsistency wouldn't seem odd at all. All my
examples meet the rule: LocalDate(year, month, day), List(items) and
Map.Entry(key, value).

Stephen