On 04/19/2012 09:45 PM, F i L wrote:
Timon Gehr wrote:
struct Foo {
struct Unsafe {
static:
string name;
void bar() {
writeln(name); // fine
}
}
}
Foo.Unsafe.name is static and not per-instance. That's a completely
different thing than having a "namespace" within the object which serves
only as a semantic layer to classify property access.
Ah, I see what you are getting at. I failed to read your post carefully
enough. Sorry about that.
Like I said, it's completely possible with templates today, you just
have to alias them for nice syntax. Parameterless templates
It is not really a 'template' if it is parameterless and does not need
to be instantiated.
Sure it is. Templates provide a semantic convenience over reusable bits
of code that get resolved at CT. It's more like a CT struct than a CT
function.
It is a parameterized scope that is analysed upon instantiation.
So it makes perfect sense to have parameterless ones,
especially because you can already have that, only with less pretty code.
This is an alternative:
private template _unsafe(){
string name;
void bar() {
writeln(name);
}
}
struct Foo{
mixin _unsafe Unsafe;
}
Is this better? (_unsafe can be a local template of struct Foo, but then
it invades the allMembers)
In fact, this pattern could be generalized to
template Classify(string s){mixin(s);}
struct Foo{
mixin Classify!q{
string name;
void bar() {
writeln(name);
}
} Unsafe;
}
With the alternate alias syntax, this would then probably work as well:
template Classify(string s){mixin(s);}
struct Foo{
mixin Unsafe = Classify!q{
string name;
void bar() {
writeln(name);
}
}
}
would just
be sugar, but that sugar would be nice when you want to use
classifications like this in real code.
This idiom imho shouldn't be overused. Renamed imports usually suffice.
I don't see how import renaming applies to what I've suggested. It's a
completely different topic.
It is similar, but here it does indeed not apply.
I'm sure it could be abused, like anything
else, but It is useful in some areas, and I don't see any reason not to
have a usable syntax for something that's already achievable in D.
I think the current syntax hardly qualifies as unusable. I agree that it
is not the prettiest/most specific one imaginable.
Honestly I think this could be another "nah nah nah, look what our
language can do" bullet point in D's favor. So far as I know, no other
(efficient) language can sub-classify it's objects without increasing
their per-instance memory footprint + require manually wiring up the
connection. While in D it's simply an emergent feature of a beautiful
template design.
Well, it can do it already.
D gives more control over the structure of objects than any other
language, without sacrificing a thing. That sounds like a good marketing
point to me :)
D's design sacrifices ease of implementation to some extent.
