January 06, 2009
(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)


Please, state critical remarks
January 07, 2009
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

> Please, state critical remarks
January 10, 2009
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.)
January 10, 2009
On Wed, Jan 7, 2009 at 4:22 AM, Weed <resume755@mail.ru> wrote:
> (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)
>
>
> Please, state critical remarks

Your English is really hard to make sense of.
That's my guess for why there are no responses.
Heck, I'd *like* to respond, but I just can't tell what you're trying to say.

--bb
January 10, 2009
On Sat, 10 Jan 2009 04:02:59 +0300, Weed <resume755@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. Не унывай! :)
January 10, 2009
Denis Koroskin пишет:

> 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

This way does not approach because scope value is impossible to return from function.

> 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.

I am not understand what here a problem with class inside other class.

> 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.

I still was not sure what syntax could. While I operate with the such - probably, it don't break an existing code:

class C {}
struct S {}

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

C c(); // stack-allocated (added by me)

Brackets () do not allow to mix object with the reference. Also, they may contain constructor parameters.

Further objects are used as usually.

> 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:

Inheriting of structures is necessary for convenience of replacement "struct" to "class" and vice versa. Therefore possibility of replacement of struct inheritance on other constructions it is not essential.


> 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.

I agree, but the changes offered by me separately look as unreasonably, and only in the sum they yield good result.

Thanks for kind words :)
January 10, 2009
Bill Baxter пишет:

>>
>> Please, state critical remarks
> 
> Your English is really hard to make sense of.
> That's my guess for why there are no responses.
> Heck, I'd *like* to respond, but I just can't tell what you're trying to say.

All is absolutely poor? If not everything, can you select that demands the explanation?
January 10, 2009
Denis Koroskin пишет:

> 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).

The extra-short formulation of my idea:
Objects should be divided on POD (struct) and non-POD (class).

Instead of such division as now: POD && value type (struct) and POD &&
reference type (class).
January 10, 2009
Weed wrote:
> Denis Koroskin пишет:
> 
>> 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).
> 
> The extra-short formulation of my idea:
> Objects should be divided on POD (struct) and non-POD (class).
> 
> Instead of such division as now: POD && value type (struct) and POD &&
> reference type (class).

The reference versus value type difference is just a matter of defaults.

Returning a class instance on the stack from a function is possible with inout parameters, though you can't use a constructor in that case:

void main ()
{
	scope MyClass obj = new MyClass;
	foo (obj);
}

void foo (inout MyClass obj)
{
	// initialize obj somehow
}
January 10, 2009
Christopher Wright пишет:
> Weed wrote:
>> Denis Koroskin пишет:
>>
>>> 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).
>>
>> The extra-short formulation of my idea:
>> Objects should be divided on POD (struct) and non-POD (class).
>>
>> Instead of such division as now: POD && value type (struct) and POD &&
>> reference type (class).
> 
> The reference versus value type difference is just a matter of defaults.
> 
> Returning a class instance on the stack from a function is possible with inout parameters, though you can't use a constructor in that case:
> 
> void main ()
> {
>     scope MyClass obj = new MyClass;
>     foo (obj);
> }
> 
> void foo (inout MyClass obj)
> {
>     // initialize obj somehow
> }

Problem not only with constructor calling.
This way does not works for temporary objects. For example, at operator
overloading in expression like a = b + c + d.
The case in detail was considered in this thread:
"division of objects into classes and structures is bad",
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81359

Also, it impossible to create an array of scope objects.