>Tough words! :-)
We are still friends I hope ;-)
> The one and only reason for having the model handling the bounding boxes is
> the wish to handle alien figures in a reasonable way.
Good point. Like I said in an earlier mail to you, I am using Graph
as a starting point and I am enjoying the fact that you have designed it
in a competent way. I do not even understand all the details like
operations, and as I now learned also those aliens. Extending
source code without understanding it is called "grey box design"
I believe ;-)
[snip]
> In that way, the above code pattern reliefes a client programmer from some
> debugging. Even more: it is better documenting. By having the browser to list
> an abstract method (and a final, non-extensible one), the framework designer
> communicates quite clearly that there is a slot that must be filled by the
> extension (and one which has been filled already is not to be touched
> anymore). Compare this to situations with implemented but extensible
> procedures. I never know what to do, overwrite it, and if I do, to call super
> or not to call super? I am now talking of the more general pattern, not the
> relatively well-known externalize / internalize situation.
Thank you for the example. I will perhaps use supercalls
for the time being, and switch to your solution later when my package
is debugged, and when I fully understand ramifications of your design
pattern.
BTW, the traffic in this list is encouraging. Reportedly, Professor Wirth
said recently that his spin-off company was "not very successful", what
sort of casts a shadow of doubt whether using BB is a good idea
to begin with. It is encouraging to me that the mailing list is alive and well.
Thank you again for the response.
Wojtek