D vs. placement new (for classes) aka why D needs .sizeof and

[Sean Kelly]

Dan wrote:
>
> Inheritance:
> 
> Inheritance is something I tend to disagree with
...
> I argue the better methodology is to implement interfaces

Funny.  I just finished "Prefactoring" by Ken Pugh, and he seems to feel 
the same way.  One reason seemed to be that it's easier to add or change 
interface compliance than it is to restructure an inheritance hierarchy. 
  And for implementation sharing, it's often just as easy to abstract 
the common bits into support objects.

> Encapsulation:
> 
> Oddly, Java Programmers(tm) tend to think that encapsulating a
> property and providing a simple getter and setter for it is somehow
> a good thing.  I argue that you're cluttering your NS with redundant
> information, and causing your code to jump into the getter and setter
> method every time you access a property without adding anything useful.

The argument for Java is that if everything is abstracted through 
get/set methods then there is a common point of analysis for debugging 
and it is painless to add additional functionality, change 
implementation, etc.

Since D has property syntax however, the argument for starting out with 
everything hidden behind get/set methods is a bit weaker.  If you have 
public data and later decide to hide it behind get/set methods, you can 
often do so without changing syntax from a user end.

I don't think efficiency is an issue however.  Get/set methods are 
almost always inlined, so there should be no performance penalty.

> Drawbacks of Classes:
> 
> Classes lack transparency.  You don't know the size, the location,
> the alignment... there is code and structure within them you aren't
> aware of, and much of it is often unneccassary.  You cannot
> intelligently manipulate the implementation of a class even internally
> - such as iterating through an array of them and accessing a property
> simply by adding the sizeof to an iterator.

I'm not sure it's really as bad as all that.  Knowing class instance 
size at compile-time would be useful for some storage methods, but data 
order and such shouldn't be an issue.  However, the .tupleof property 
implies that class data will typically be stored in declaration order 
anyway, since to do otherwise would complicate things unnecessarily.

> You cannot pass a class by value, while a struct can be passed by
 > value or reference.  You cannot easily duplicate an Object instanciated
 > from a class.  You cannot declare an instanciated Object literal, but
> you can declare such a struct.

Personally, I think it's actually a good thing that classes can't be 
passed by value.  It's a bit of a change from C++, but it dramatically 
simplifies some things that are difficult to impossible in C++.  For 
example, one idea being discussed for multithreaded C++ 0x is to pass 
uncaught exceptions to the joining thread.  Because exceptions are 
typically allocated on the stack and thrown via copying, this is not at 
all easy, but in D I was able to implement this in about five minutes.

> These shortcomings I feel are sufficient to warrant the use of
 > structs unless you are implementing an interface which other
> programmers will use in their own code (read: library), or
> getters/setters/ctor/dtor are critical to the legible implementation
> of something such that a good-old-fashioned method on the struct
> won't do.

Without copy semantics (which I'm not sure structs should have), the use 
of structs is somewhat limited in D.  For the most part, I think they 
really are best as aggregates.  But this difference between classes and 
structs is good justification for both to exist in the language.


Sean