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

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.

"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

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

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.