Andy Smith's Blog

So if “non virtual by default” is the right thing for c#... Then why isn’t “sealed by default” the right thing too?

It seems to me that if we are supposed to be testing extensibility points and purposefully allowing derivation and overriding for specific scenarios, then it seems to me that classes should be sealed by default, until we know that we acknowledge those scenarios.

Now, I’m not taking a stance here on the virt/nonvirt issue here. I really don’t care. But it just seems to me that “sealed by default” is the logical extension to the c# team’s points for their design, and I’m genuinely curious as to why they chose a different model at the class derivation level.

I just got back from one of my semi-regular midnight-ish walks after a long day of coding. It was a fairly windy nite, and the trees were fairly alive with the creaks and the rustling… so they were attracting my attention.

Back in the day, I was majoring in studio art, with plans to go into graphic design or 3D animation. One of my more intriguing assignments was to draw a tree, to draw a single tree from at least 5 different perspectives. Of course, the main goal was to learn about 2D design. However, one of the more subtle goals was to get you looking at natural structures, taking the time to really look at how they are built in an evolutionary way. “This fork in the branch built big and strong because of conditions that provided better light and constant pressures like wind.”

Then I jumped to a memory of later using a program that built 3D models of trees for import into animation packages. It was fairly good, but at that point I had a fairly good understanding of what trees really look like. The program did a passable job of making these structures that were obviously trees, with properties that could tell you what kind of tree it was… but at the same time, you could easily tell that it built with an algorithm. There was never any account taken for the effects of the environment. No leaning away from the prevailing wind direction… No broken branches…

But anyway, back to my point. I was thinking on my walk that it would be utterly fascinating to try to write that tree-creation program. The truth is that most people have no idea what a tree looks like. Sure, people can recognize a tree, but that’s not the same as being able to describe how a tree is built. A first run thru of a tree making algorithm might simply start with a trunk, and at random points, have it split out at some random angle within a range to make a branch, until you get the general shape of the tree type you are making. And that might even impress somebody. But that’s not how trees work.

Obviously, I’m not going to bust out any code here. I really don’t have the energy to really get into it any time soon. It would be a huge job to really make a good tree. But it seems to me, that if one day I had all the resources I wanted… that’s the kind of project that I would immensely enjoy tackling for my own private collection of Things I’ve Looked Into.