www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - structs, classes, interfaces - Part I, Motivation

reply Martin Hinsch <m.hinsch rug.nl> writes:
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 rug.nl
+31 50 363 8097

CEES Centre for Ecological and Evolutionary Studies
Biologisch Centrum
Kerklaan 30
Postbus 14
9750 AA Haren
Sep 01 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Martin Hinsch Wrote:

 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 rug.nl
 +31 50 363 8097
 
 CEES Centre for Ecological and Evolutionary Studies
 Biologisch Centrum
 Kerklaan 30
 Postbus 14
 9750 AA Haren
 
Someone probably pointed it out in the other thread, but structs do have encapsulation/private data members.
Sep 01 2007
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Robert Fraser" wrote
 Someone probably pointed it out in the other thread, but structs do have 
 encapsulation/private data members.
Really? How is this done? I just tried this: struct X { private int _y; int y() { return _y; } } int main(char[][] args) { X x; x._y = 5; return 0; } Compiler doesn't complain... I also noticed on this page http://www.digitalmars.com/d/struct.html that structs don't allow "hidden members" but offer "member protection." As these two things seem equivalent to me, I was wondering if someone could explain the difference. -Steve
Sep 07 2007
next sibling parent Matti Niemenmaa <see_signature for.real.address> writes:
Steven Schveighoffer wrote:
 "Robert Fraser" wrote
 Someone probably pointed it out in the other thread, but structs do have 
 encapsulation/private data members.
Really? How is this done? I just tried this: struct X { private int _y; int y() { return _y; } } int main(char[][] args) { X x; x._y = 5; return 0; } Compiler doesn't complain...
In D, protection attributes apply only across modules. In the same module, everything is public. If you've used C++, think of it as everything in a module being implicitly "friend" with each other. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Sep 07 2007
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Steven Schveighoffer wrote:
 "Robert Fraser" wrote
 Someone probably pointed it out in the other thread, but structs do have 
 encapsulation/private data members.
Really? How is this done? I just tried this: struct X { private int _y; int y() { return _y; } } int main(char[][] args) { X x; x._y = 5; return 0; }
Try declaring the struct in another module. Within a module, everybody is a friend, including classes.
Sep 07 2007