structs, classes, interfaces - Part I, Motivation

[Martin Hinsch]

The problem of the dichotomy between structs and classes as well as
between value and reference semantics has been discussed
several times before and I'm sure everybody is bored to death by the
subject right now. Anyways I'm going to add my own thoughts to it ;-).

This post comes in three parts:
I will start off by explaining why this dichotomy is a problem (in certain
situations). In part II I'll go on a bit about why I think it exists in the 
first place. In part III I will propose a solution. It's kind of radical and
might be entirely unworkable but I think it's interesting enough to stimulate
some discussion.

On to part I...

A large part of my work as a theoretical biologist consists of writing 
individual-based simulations. That means I have programs with LOTS (up to tens 
of thousands) of relatively small objects. In every step of the main loop the
program goes through all or most of these objects and reads or manipulates them.
Depending on the specific situation there can also be a lot of turnover, i.e.
objects are removed and created quite frequently. Add to that the fact that 
faster simulation make it possible to run more parameter combinations (=>
more data => nicer results => fame and fortune ;-) and you can see that arrays 
containing values and thus structs are the way to go. That means however no 
inheritance, no encapsulation, no OOP. This already sucks per se but even more
if you have teach or cooperate with students with little programming experience.
They have a hard time structuring their code properly anyways and it really
helps when you can just tell them to make all members private so that the 
compiler can help them keeping stuff encapsulated.

I'm sure this is a very specific situation but for me it's really *the* point
preventing me from using D.


-- 
Martin Hinsch

m.hinsch at rug.nl
+31 50 363 8097

CEES Centre for Ecological and Evolutionary Studies
Biologisch Centrum
Kerklaan 30
Postbus 14
9750 AA Haren