Fully dynamic d by opDotExp overloading

[davidl]

在 Sun, 19 Apr 2009 02:16:30 +0800，Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 写道:

> bearophile wrote:
>> Andrei Alexandrescu:
>>> Yes. The amount of confusion in this thread is staggering.
>>  I think I have misunderstood about the whole thread then. If the  
>> string isn't determined at run time, then this thing isn't useful for  
>> my purposes, and it's not close to the object-C as I was talking about,  
>> and it's not similar to __getattr__ of Python, etc.
>>  Bye,
>> bearophile
>
> In the syntax
>
> a.b
>
> how would either of a and b be identified at runtime? I mean, you write  
> the code somewhere and it gets compiled. It's not like you're reading  
> "a.b" from the console and then call some eval() function against them.
>

Depends on the compiler semantic. The compiler can feed the opDot with the  
variable b if it's a string. The compiler can intepret the opDot that way.  
Consider:

string b = "myfunction";
dynamo.b(1);

we can translate this to dynamo.opDot("b",1); and we can also rewrite this  
to dynamo.opDot(b, 1);( if there's a non-template version of opDot just  
like the current one I have) and even more we can let the compiler decide  
which rewrite version it prefers, because compiler can simply firstly try  
to query if there's a variable named b with type of string in the scope of  
caller. There's someone posted this sort of dynamic language semantic, and  
I was astonished and thought it were impossible under the opDot scheme.  
Yet till now, I finally realize that the compiler gets all source input  
just as the dynamic language interpreter gets input from a console. There  
won't be much barrier blocking us from mocking every dynamic features.  
Just we need to be careful to choose some useful part and equip our static  
land without much potential risk while developer friendly interface.

I have not and don't intend to choose the second rewrite version. Whether  
we should go the second version is left for more discussion. I think many  
static language developers won't enjoy the second rewrite version at the  
first glance. I didn't like it either. Yet, after consider a little bit  
longer, I start to think it might not be as that bad as the first  
imagination impression in our own mind.

It can be funny to have some code like:

string doSomething;
if (animal = "dog") doSomething="bark";
if (animal = "human") doSomething="talk";
dynamo_animal.doSomething();

Ok, this may look pretty evil in a static language for many among us. I  
need to claify that I don't intend to go into that direction till further  
discussion will be made.

The first rewrite version and revised by your template suggestion should  
be able to do the __getattr__ trick, if I get the idea of __getattr__  
correctly. I think bearophile's worry can be alleviated. ;)

>
> Andrei



-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/