opStar

[guslay]

If you think of classes with opStar() operator as classes that have "Proxy" behavior, it makes a lot of sense to have object->member() mean "forward the invocation to another object", the object returned by opStar().


Note that it is not the same as -> in the C world, which means "call member through pointer". Here -> is not applied to a pointer (not on the surface at least), its applied to the "proxy" object.


Smart pointers and iterators, unlike straight pointers, cannot be unambiguously assimilated to the object referred to. They are wrappers to an object. Blurring that line with a of the "." that is sometime dereferenced, sometime not, seems a little bit tricky to me.




Bill Baxter Wrote:

> 0ffh wrote:
> > Bill Baxter wrote:
> >> Or instead of .deref you could call the property something like, oh i 
> >> dunno, "opStar".  ;)
> > 
> > Now, there's a novel thought! ;)
> > BTW might it be that this is an example how Perly syntax kluges like
> > automatic dereferencing of *struct members can get you into trouble?
> 
> Or just how making special cases in general gets you in trouble.
> 
> But actually I don't think there's that much trouble here.
> 
> First, let's call it opDeref because, to quote Walter re opAdd:
> """
>    The reasons for "opAdd" instead of "operator+" are:
>    ...
>    3) it encourages the use of operating overloading for arithmetic
>    purposes, rather than "parse this predicate once", which happens with
>    C++ operator overloading.
> """
> http://lists.puremagic.com/pipermail/digitalmars-d/2006-October/009478.html
> 
> 
> Second, the only thing that makes sense if you're going to have smart 
> pointers is to make them act in every way possible like regular 
> pointers.  Iterators are just the underevolved Neanderthal ancestors of 
> smart pointers, but they're still smart pointers of a sort.
> 
> So we have to make "x.member" call "x.opDeref.member" if x is something 
> with an opDeref.
> 
> Third: we need to figure out some way to actually get at x's own members.
> 
> I think there are a number of ways you could do that.
> 
> 1) In D, the magic pointer dereferencing will only dereference one 
> level.  So that means if x is a struct with opDeref, then (&x).member 
> will give you a member of x itself, not of the opDeref.
> 
> 2) Make a special property that if used disables the opDeref.  Maybe 
> even x.this.member could be used for that.  Actually, I think because of 
> 1) that should work automatically if x is a struct.
> 
> 3) Introduce an alternate member access syntax for 'raw' member access. 
>   Like x:member, x::member, x->member,  x..member.
> 
> 
> Option 1) seems the most reasonable to start with, since it shouldn't 
> actually require doing anything.
> 
> --bb