So I’m not sure how much we can learn from this particular
example. Maybe you have a better one?
No a better one, just another one, you want to be able to declare a
deconstructor abstract by example on an interface
interface Map {
interface Entry<K,V> {
public abstract deconstructor Entry(K key, V value);
}
}
Yes, valid goal, but now you're getting ahead of the story. There is a
plan for the "instance method analogue" of pattern declarations, but
it's not called a "deconstructor", any more than a method is not called
a constructor.
The basic story is:
- patterns are declared as members
- some patterns are static (Optional.of(var x)), some are instance
(Map.contains(k, var value)), and some are the same weird mix that
constructors are (deconstructors)
- Deconstructors are total (they deconstruct only), but the others are
partial (they ask a question)
Right now, we're looking only at the simplest kind of declared pattern
-- deconstructors -- and building from there.
...
for(Map.Entry<String, String>(var key, var value) : entries) {
...
}
BTW, it's also an example where 'var' can be useful instead of having
to specify the full type
for(var(var key, var value) : entries) {
...
}
I get that you can write the code like this if baseSalary is declared
private in Employee
class VP extends Employee {
int bonus;
deconstructor VP(int salary) {
super(var baseSalary) = this;
return (baseSalary + bonus);
}
}
still, a deconstructor is unlike a constructor because you can call a
constructor directly something you can not do with a deconstructor.
You cannot call a constructor directly either! You execute a "new"
operation, which has multiple consequences, only one of which is calling
the constructor to fill in the state of the object. The same is true
with deconstructors -- you do a pattern match, which, under the right
circustances, causes the deconstructor to be called.
