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.


Reply via email to