opIndexAddAssign? ...

[Jarrett Billingsley]

"Manfred Nowak" <svv1999 at hotmail.com> wrote in message 
news:eqi90k$kf5$1 at digitaldaemon.com...

> Your intention seems to bind an operation to the valuetype of the AA.
> But you have bound it to the AA directly and not to the valuetype.

So, if all we had was opIndex that returned inout, you're suggesting I 
implement a new class for the value type of the internal container every 
time I want the behavior of index assigning to change?  That seems a little 
overkill.

Besides, the code I posted is an example.  I'm just trying to say that an 
inout-returning-opIndex doesn't allow you to do anything with the value 
that's added to this.

> The code
>  instance[ key]= value;
> should be called approximately as
>  instance.opIndex_l(key)= typeof( mData[key]).opAssign( value)

Again, if my internal data structure for instance is just an:

int[] mData;

then I can't have the "mData[key] = value % 10;" like in the opIndexAssign 
version.  I'll have to create a proxy class to hold the data which modulos 
its value by 10 whenever opAssign is used, and make an array of that, and 
create all those class instances.  God, it's starting to sound like Java.

> In fact your example is not that easy because it is unclear what the
> return value of opIndex( int) would be:
>  mData[key]
> or
>  mData[key] * 10

That's not what I'm really getting at.. I'm talking about adding or setting 
an index of a container type, not getting one.

> or void as your opIndexAssign suggests?

I find chaining assignments and using assignments in conditionals (i.e. 
"if((x = nextThing()) == 0)") to be in bad form, so I always make my 
opXxxAssign and property setters return void so you can't do that.  It's 
just a personal preference.