Timon Gehr wrote:
Ah, I see what you are getting at. I failed to read your post
carefully enough. Sorry about that.
Hakuna matata ;)
It is a parameterized scope that is analysed upon instantiation.
Yes, but my request is to have an un-parameter-atized syntax
which is sugar for a template with zero parameters and is useful
for sub-scoping objects. See below for a more detailed argument.
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)
Not really. Reasons is I actually want _unsafe to be part of
allMembers, but I also want to use it in a syntactically
appealing way. Also, by separating the template from the object,
you're (conceptually) breaking OOP design, unless _unsafe is
designed as a reusable packet of code (ie, used by more than just
Foo, like UFCS), which isn't the goal I intended. Here's another
example:
class Fighter : Ship
{
template visual {
VisualMesh mesh;
void update() { /* use visual.mesh */ }
void updateAfter() { /* ditto */ }
}
template physic {
CollisionMesh mesh;
void udpate() { /* use physic.mesh */ }
}
void update() {
visual.mesh.doSomething();
physic.mesh.doSomething();
}
}
Now we have three functions "update", and two fields "mesh",
without any conflicts because they're separated by scope. The
classic way to do this is simply to prefix the names: visualMesh,
visualUpdate, physicMesh, etc... but scoping fits with OOP
design, and allows each sub-scope to use each variable without
prefixing, eg, "visual.update()" doesn't need to prefix "visual."
when using "visual.mesh".
I know that this can be today, though alternative ways. However,
this requires very little prior knowledge of D's idioms to
understand. Meaning non-D programmers will understand this at a
glance. It makes sense, and code is where it should be, saving us
all a little bit of head-ache.
What may also be prudent, is to have parameterless mixin
templates, something like:
struct Person
{
mixin intros = template {
void sayHi() { ... }
void sayAge() { ... }
}
void sayHi() {
intros.sayHi();
intros.sayAge();
}
}
void main() {
auto philip = Person();
philip.sayHi();
philip.sayAge();
philip.intros.sayHi();
}
The problem with always using mixin templates is that sometime
you want to require the scope prefix, like in the Ship example
above.
I think the current syntax hardly qualifies as unusable. I
agree that it is not the prettiest/most specific one imaginable.
Agreed, though I don't see that as a reason to not *eventually*
introduce a more usable syntax. If I had more time to dick around
with DMD's internals, I'd make a pull request myself. I'm
learning it, but it'll be awhile before I'll be trying to push
code.
Well, it can do it already.
Yes it can, but just even simple realiasing a template (or
separating it out like your examples) requires a deeper
understanding of D than what's graspable from my simple Ship
example above. The easier to grasp, the more passing developer it
will impress.
D's design sacrifices ease of implementation to some extent.
I don't think it needs too, though. We could have both.
