V Sat, 14 Jan 2017 01:28:51 +0000
André Puel via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:
> On Friday, 13 January 2017 at 23:13:43 UTC, Daniel Kozak wrote:
> > On Friday, 13 January 2017 at 22:12:55 UTC, André Puel wrote:
> >>
> >> Could you elaborate on why you consider it important to be
> >> able to tell when you use mixin and when not?
> >
> > because it is something really different, so it is nice to know
> > when you call something and when you mixin some code into
> > curent scope.
>
> Yes, please, elaborate on that. Why is it really different? What
> are your thoughts on C macros?
>
> >
> > Btw. I was on a same side as you are now (I am still in some
> > way, I would prefer some shortcuts)
> >
> >> In D, you don't know if a member is a function call or an
> >> attribute when you access it without parenthesis:
> >>
> >> myObj.a; //Is it a function call or an attribute?
> >>
> >
> > Not completly true:
> >
> > class MyClass
> > {
> > int a;
> > void b() {}
> > }
> >
> > void main()
> > {
> > auto myObj = new MyClass;
> > myObj.a; // this does not compile
> > myObj.b;
> > }
>
> I meant the property pattern. You access an attribute and it
> could be a direct access in the memory or it could be a request
> to a remote database. One happens instantly, the other got a lot
> of complex things in the way. You could even get a thrown
> exception by just accessing an "attribute".
I do not like C macros.
It is different because when anyone see something like this:
someNameOfFunction();
He or she would expect that this call something and it could not interact with
current scope (declare new local variables, change theirs values and so on).
but if we allow use same call convention for mixins we end up with something
like this
string someMixin()
{
return `a = 5;`;
}
void main()
{
import std.stdio;
int a = 4;
someMixin();
writeln(a); // wow 5 insted of 4
}
right now when I see
mixin(someMixin());
I know I need to introspect someMixin to be sure what can happend
