digitalmars.D - structs, classes, interfaces - Part I, Motivation
- Martin Hinsch (36/36) Sep 01 2007 The problem of the dichotomy between structs and classes as well as
- Robert Fraser (2/47) Sep 01 2007 Someone probably pointed it out in the other thread, but structs do have...
- Steven Schveighoffer (22/24) Sep 07 2007 Really? How is this done? I just tried this:
- Matti Niemenmaa (7/31) Sep 07 2007 In D, protection attributes apply only across modules. In the same modul...
- Lutger (3/23) Sep 07 2007 Try declaring the struct in another module. Within a module, everybody
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
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 HarenSomeone probably pointed it out in the other thread, but structs do have encapsulation/private data members.
Sep 01 2007
"Robert Fraser" wroteSomeone 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
Steven Schveighoffer wrote:"Robert Fraser" wroteIn 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) fiSomeone 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...
Sep 07 2007
Steven Schveighoffer wrote:"Robert Fraser" wroteTry declaring the struct in another module. Within a module, everybody is a friend, including classes.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; }
Sep 07 2007