A peek at the roadmap for pattern matching and more

[Brian Goetz]

>
> Whereas I can more easily understand that the job of
>
>     public deconstructor Point(int x, int y) {
>         x = this.x;
>         y = this.y;
>     }
>
> is to take values out of the object “this” and put them into separate 
> _variables_, not a new object.  (Granted, these variables have a 
> somewhat new and mysterious existence and character.)

And ...

It is very easy to look at things from the perspective of the language 
we have, and say "that's just a method, it should look like a method."  
This looks like it doesn't add new abstractions that the user must 
understand, and that's often the right move.  But really, we should look 
at it from the perspective of the language we _want to have in the future_.

IMO, that the language does not have deconstructors yet looks to me like 
a gaping hole!  A key principle of OO is _mediated access to 
encapsulated state_.  That is, we hide our representation, and then 
expose behavior that mediates access to a relevant subset of the state, 
adding validation, copying, adaptation, etc along the way. But why do we 
have mediated aggregration, mediated access, but not mediated 
disaggregation?  Why must every object creation be a one-way trip?  (Or, 
if not, why must the return trip look nothing like the outbound?)  
Something is missing.

By framing deconstructors as the arrow-reversed form of constructors, we 
provide the missing edges in our graph in a symmetrical way.  By framing 
deconstruction as merely a "multi-getter", we may provide the missing 
edges, but the result is badly asymmetric.