This relies on the possibility to replace the body of an inside-out object, (normally an undefined scalar) with some foreign object of any provenience, (also a scalar in this case, but with significant content) so that its methods work without a hitch. This approach won't work with a hybrid class where the body is required to be code.
(++) x As::Much->as('possible'); (which unfortunately is only 1) both for the intrinsic educational value of your post and for the nifty example you came up with. Perhaps all this may be the basis for a future tutorial... OTOH I must admit I'm such a blockhead that while I could understand at a glance why all this worked and grasped the beauty of the scheme, initially I could not see what would have gone wrong with "my" implementation, but eventually I did.
Said this, I know I could find out by experimenting myself and reading the docs, but I seem to notice that "this kinda things" tends to present more possibile gotchas waiting in the shadow to bite you in the neck than one on average would expect, so I'm asking directly: if the implementation is a pure Inside-Out ref-agnostic one and deref overloading is used as in the above, can one reliably use dereferencing "as a shortcut" (supposing that in a realistic case that would be part of a documented public interface) in the derived class implementation?
In reply to Re^4: Agile syntax (abuse?)
by blazar
in thread Agile syntax (abuse?)
by blazar
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |