It's because i think we don't need to single out deconstructor from
the rest of the other methods that can be called by a pattern.
I get why you think that, but I think that would be a serious mistake.
Constructors have a number of subtle differences from ordinary static
methods -- and it
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "amber-spec-experts"
> Envoyé: Jeudi 7 Janvier 2021 23:02:36
> Objet: Re: New pattern matching doc
>> Hi Brian,
>> i'm glag that "deconstructor" can now be virtual.
> Can you point to where in the doc you got that idea? A deconstructor is the
> dual
Hi Brian,
i'm glag that "deconstructor" can now be virtual.
Can you point to where in the doc you got that idea? A deconstructor
is the dual of a constructor. A constructor is not a virtual member,
nor a static member; it takes a receiver, but is not inherited and
cannot be overridden.
- Mail original -
> De: "Florian Weimer"
> À: "Remi Forax"
> Cc: "amber-spec-experts" , "Brian Goetz"
> , "Amber Expert
> Group Observers"
> Envoyé: Lundi 4 Janvier 2021 23:24:01
> Objet: Re: Diamond in type patterns?
> * Remi Forax:
>
>> Should we allow the diamond syntax in a cast ?
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mercredi 6 Janvier 2021 21:52:19
> Objet: New pattern matching doc
> I have pushed
> [
> https://github.com/openjdk/amber-docs/blob/master/site/design-notes/pattern-match-object-model.md
> |
> https://github.com/openjdk/amber-docs/blob/mas
- Mail original -
> De: "Brian Goetz"
> À: "Remi Forax" , "amber-spec-experts"
>
> Envoyé: Lundi 4 Janvier 2021 20:42:34
> Objet: Re: Diamond in type patterns?
>> If you use pattern matching without inference, the mix between parenthesis
>> and
>> angle brackets rapidly becomes unreada
Hello!
While I like the idea in general, what is annoying is the necessity to
repeat the expression type in every pattern:
This is a "primitive" -- the array analogue of the type pattern -- but
other things can build on it. Varargs patterns will build on it (as
shown in the mail); if and
