new principle of division between structures and classes

Denis Koroskin 2korden at gmail.com
Fri Jan 9 21:35:32 PST 2009


On Sat, 10 Jan 2009 04:02:59 +0300, Weed <resume755 at mail.ru> wrote:

> Weed пишет:
>> Weed пишет:
>>> (Here I generalise my sentence with supplement)
>>>
>>>
>>> The POD data and the data supporting polymorphism are necessary to us.
>>> POD the data is stored in structs and polymorphic objects is classes.
>>>
>>> Both types (class and struct) can be instanced in a heap or on a stack.
>>> (And in invariant ROM too, but there it is not important)
>>>
>>> Classes and structures support inheritance. But structures do not
>>> support polymorphism (as are POD type without vptr) - at attempt to
>>> implement virtual function in structure the compiler will give out an
>>> error: "struct StructName is POD type, it is not support polymorphism,
>>> use class instead of". (And certainly structures are not inherited from
>>> classes, including from super class Object)
>>>
>>> Thus, the programmer always knows the object is POD-data or not. The
>>> problem of simple alteration of structure to a class and vice versa  
>>> when
>>> necessary also solved.
>>>
>>> For an exception of splitting of objects it is necessary to check  
>>> during
>>> compilation: or to forbid assignment on value for types not being to  
>>> the
>>> data (how now it works for the structs objects on value) or to forbid
>>> the access to the fields added at descending inheritance (its more
>>> difficult but desirable)
>>
>> And similar it will not break an existing code
> (If for a while to keep support "scope")
>>
>>> Please, state critical remarks
>
> Tell, what it is necessary to make that discussion of this question has
> taken place?
>
> I in despair. I even think to wait supports 2.0 in open source compiler
> using LLVM and to add there this functionality (I hope, my skills will
> just grow for such operation.)

I'll explain here what *I* think about.

There are a lot of topics concurrently discussed in D newsgroups. I am interested in some of them, others I skip.

I usually skip your posts because they are a pain to read and have little of interesting ideas.

Perhaps I am wrong and didn't fully understand your idea, but I don't think we reconsider class/structs design. I believe the design is sound and I don't think anyone (expect you) would like to have these basic language principles changed. As such, the whole idea is pretty much a "dead horse" and I don't want to shoot it by contributing to it.

If it was a forum and I were a moderator I'd just close the topic to stop spreading confusion, but that's just me.

Back to topic, C++ doesn't have any meaningful separation between classes and structs. D does - (one of it is that) classes are heap allocated by default whereas structs are stack allocated by default. You can override either behavior:

class C {}
struct S {}

C c = new C(); // heap-allocated (default)
S s = S(); // stack-allocated (default)

scope C c = new C(); // stack-allocated
S* s = new S(); // heap allocated

One problem I see with it is that the syntax is so much different, but that's another topic.
Other one is that the following works for local variables exclusively, i.e. you can't have class instance aggregated inside another class by value. Yes, I think there is a room for improvement but it is of little priority for me.

You don't provide use cases nor examples of possible syntax, but they are crucial for understanding.

What else?

Struct inheritance - yes it is nice to have, even without polymorphism. It was proposed many times but with no success. Someone suggested to use aggregation and opDot instead and allow implicit cast of pointer to struct to pointer to struct's first element to emulate inheritance:

struct Foo
{
    void fooMethod() {}
}

struct Bar
{
    Foo foo;
    Foo* opDot() { return &foo; }
    float f;
}

Bar* bar = new Bar();
bar.fooMethod();

Foo* foo = bar;

But it didn't have Walter's support either (and I understand why).

I'd suggest you to state you ideas as simple and keep your posts as small as possible (trust me, few people like reading long posts). You could also ask someone to check your post before submitting - this will increase the probability of your message to be read and understood.

P.S. Не унывай! :)



More information about the Digitalmars-d mailing list