On Sat, 10 Jan 2009 04:02:59 +0300, Weed <resume...@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. Не унывай! :)
