DConf 2015?

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 24 December 2014 at 09:22:17 UTC, Kagamin wrote:
> According to javascript convention, if you stored a delegate in 
> object's property, d.foo.bar("hello! ") is still a method `bar` 
> called on a value from property `foo`, it's forwarded 
> internally to the delegate when `bar` happens to be a property.

Yeah, it doesn't exactly work like that in D though due to this 
and @property being different.

I do have a way to handle the this:

foo.bar._function = (var _this, var[] args) { };

The _function is the internal representation - that's what's 
auto-generated when you assign a regular D function to it. But 
since D doesn't have a dynamic this keyword like javascript 
(which is good btw!), you can't access it unless you write a 
function in that form directly.

Like JS though, the var type does have a .apply() method which 
calls in that form.

My little script language does have a JS style this which works 
the same way. (My language isn't javascript - I changed a few 
things, removed some, added others, but it is close enough that 
it shouldn't be too surprising to a javascript user.)



What's disappointing with D's @property is that it doesn't 
actually do anything. All the foo.bar on var calls @property ref 
var opDispatch(string name)(). That way, it can get and set a 
value in a single go (returning ref means some things look silly, 
like returning null is done as var a = new var; *a = null; return 
*a; .... yes, a heap allocated null. But then it can be returned 
as ref and reassigned etc. without extra work. If you want 
efficiency, keep away from the dynamic type!)

But then calling the returned var takes the extra parens since 
the first set just calls opDispatch... which is what we need to 
do anyway to just get the var!