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

[Remi Forax]

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> À: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Vendredi 29 Janvier 2021 00:12:55
> Objet: Re: Pattern method names based on existing library conventions [was Re: Pattern matching for nested List with
> additional size constraints]

> 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.


I think a deconstructor should never be partial but always total.
Here, case Optional(var v) means that the deconstructor is partial.

Having partial deconstructors means that instanceof can return false even if it's the right instance,
which is a surprising semantics in a bad way.

  Object o = Optional.empty();
  ...
  if (o instanceof Optional(var v) {
    // not called
  }



> 
> 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

Rémi