In many languages, we end up writing groups of data members and functions in our classes. Out of good practice, the data members are private and accessible through the member functions. However, this doesn't work too well with inheritance and virtual (overridable) member functions - usually it doesn't make sense to override just one function, and even when all the functions in a member group are overridden, the data members of the parent class are not: they act as dead weight which is inaccessible from outside the class, and could be potentially dangerous if other parts of the class access the members directly instead of calling the overridden functions. Sometimes complicated workarounds are used, or the data members are made protected - however, this is still very limiting and is a hassle to the programmer.
In Stardust, members can be grouped in complex and recursively-nested ways so as to avoid the above issues. A group must be overridden in its entirety, except that individual sub-groups can be overridden without having to override the parent group. When a group is overridden, any data members it contains are no longer part of the class and are not stored in memory - they are instead the responsibility of the overriding class. This frees the deriving class to use its own implementation while at the same time freeing the parent class from having to manage the memory, cloning, etc. of the original data members.
To further support this, constructors can be decorated to indicate to the compiler that they should only be used if the member group(s) they correspond to are, or are not, overridden. If the corresponding member group(s) are overridden, then constructors dependent on the member group not being overridden will seem to not exist, whereas constructors dependent on the member group being overridden will suddenly begin to exist as they had not before.
If a member function refers directly to a data member, it must be in the same group as the data member. This applies to destructors as well, which may be multiply defined anyway. A member function can be in a member group without having to use or refer to any of the other members in the group.
In many languages, we end up writing groups of data members and functions in our classes. Out of good practice, the data members are private and accessible through the member functions. However, this doesn't work too well with inheritance and virtual (overridable) member functions - usually it doesn't make sense to override just one function, and even when all the functions in a member group are overridden, the data members of the parent class are not: they act as dead weight which is inaccessible from outside the class, and could be potentially dangerous if other parts of the class access the members directly instead of calling the overridden functions. Sometimes complicated workarounds are used, or the data members are made protected - however, this is still very limiting and is a hassle to the programmer.
In Stardust, members can be grouped in complex and recursively-nested ways so as to avoid the above issues. A group must be overridden in its entirety, except that individual sub-groups can be overridden without having to override the parent group. When a group is overridden, any data members it contains are no longer part of the class and are not stored in memory - they are instead the responsibility of the overriding class. This frees the deriving class to use its own implementation while at the same time freeing the parent class from having to manage the memory, cloning, etc. of the original data members.
To further support this, constructors can be decorated to indicate to the compiler that they should only be used if the member group(s) they correspond to are, or are not, overridden. If the corresponding member group(s) are overridden, then constructors dependent on the member group not being overridden will seem to not exist, whereas constructors dependent on the member group being overridden will suddenly begin to exist as they had not before.
If a member function refers directly to a data member, it must be in the same group as the data member. This applies to destructors as well, which may be multiply defined anyway. A member function can be in a member group without having to use or refer to any of the other members in the group.