Error: xxx is not an lvalue

[Unknown W. Brackets]

You can do that something similar to that, sure.

But, you'd be implementing a class and doing an opIndexAssign.  That's 
totally different from just returning the associative array outright.

What you'd do to make a non-modifyable array is this:

class Foo(T)
{
    private T[] data;
    public ref T opIndex(int i)
    {
       return this.data[i];
    }
/*
    public ref T opIndexAssign(int i, T val)
    {
       // Do some sort of validation.
       this.data[i] = val;
       return this.data[i];
    }
*/
}

But, maybe you want the associative array to be modifiable?  For 
example, I have an XPath library, and in it I just have a namespaces 
member.  I place no logic on this, so the interface to add namespaces is 
as simple as modifying the associative array (e.g. .namespaces["xhtml"] 
= "http://www.w3.org/1999/xhtml".)

You have the control to do either one.  But, a member being private just 
means the user of the class cannot access the member *though that method 
or means*.  It does not affect the data, it doesn't make it special or 
non-modifiable, and it shouldn't.

As to your other question - there are good reasons for that.  For 
example, suppose I had a database class.  If I have an instance of the 
database connection as a member of the result class, I don't mind if you 
modify the connection through that member variable.

However, if you were to reassign the member (e.g. = new DBConnection()), 
that wouldn't make sense and could cause me serious problems.  The 
connection class can manage what parts of it you can modify or not, so 
as long as I force you to use the one I already have, I'm safe.

-[Unknown]


Tyro[a.c.edwards] wrote:
> On 5/3/2009 8:17 PM, Unknown W. Brackets wrote:
>> Well, if you really want a "protected" associative array, or array for
>> that matter, you probably should define a wrapper class that inlines the
>> access you're willing to allow.
>>
>>  From a basic perspective, _testMap is a structure of data. Although it
>> is private, there's no reason it can't be modified through an accessor.
>>
>> Without a setter, the only thing that should fail is test.testMap =
>> something. Requiring a setter for any minor change makes no sense.
> 
> I was following until now... If I can modify said private member at a
> whim, why on earth would I prevent this case? Is this because I would
> be assigning it a completely new value vice simply modifying its
> content? If that is the case, am I correct in saying that this
> characteristic is applicable only to arrays?
> 
>> Compare it to this: if you have a class that has a member object (e.g. a
>> User with a Socket member variable), should it be necessary to have a
>> setter to change the Socket? Can't the Socket handle its own
>> private/public-ness?
>>
>> Arrays and associative arrays are the same, except that the members you
>> use are public.
>>
>> -[Unknown]
> 
> Got you... I think I understand. That being the case though, wouldn't
> it be just as useful to build the same "accessor" capability into
> opAssign such that you can:
> 
>     class Foo
>     {
>         private sometype _data;
>         public ref typeof(_data) opAssign() { return _data; }
>     }
> 
>     Foo b = new foo;
>     b[0] = 1;
> 
> Why is it necessary to have a separate/different "accessor" function?
> 
>>
>> Tyro[a.c.edwards] wrote:
>>> On 5/3/2009 6:25 PM, Unknown W. Brackets wrote:
>>>> This code works fine (D 2.x only):
>>>>
>>>> class Test
>>>> {
>>>> private int[int] _testMap;
>>>> public ref int[int] testMap() {return _testMap;}
>>>> }
>>>>
>>>> void main()
>>>> {
>>>> Test test = new Test();
>>>> test.testMap[0] = 1;
>>>> }
>>>>
>>>> Note the "ref". Otherwise, a value is returned which is not modifiable.
>>>> This will also fix test.array.length. Nothing wrong here, no creepy bad
>>>> temporary property problems.
>>>
>>> Is this an intended or even desirable "feature" of the language or
>>> just something that happens to work in D 2.x? I ask because to the
>>> untrained eye, it is unclear exactly what is happening. There is
>>> nothing to inform me that _testMap can be modified from outside the
>>> class. Even with "ref" there it doesn't make it any clearer.
>>>
>>> Matter of fact, I just had a problem in Phobos 2 where a function was
>>> defined like that and I had to comment out the "ref" for it to work.
>>> Kept telling me that some array was not an lvalue. The minute I
>>> commented out the "ref", everything worked like a charm.
>>>
>>> Also it makes more sense to me to have separate functions as getters
>>> and setters. Maybe that's only because I lacking proper training in
>>> the art of computer programming though.
>>>
>>>> I suppose you could also try returning a pointer to an associative 
>>>> array
>>>> (e.g. with &) in D 1.x.
>>>>
>>>> -[Unknown]
>>>>
>>>> flourish wrote:
>>>>> Hi,
>>>>>
>>>>> why does the following code not compile -- or how to declare a 
>>>>> (usable)
>>>>> property of an associative array field?
>>>>>
>>>>> //////////////////////
>>>>> class Test
>>>>> {
>>>>> private int[int] _testMap;
>>>>> public int[int] testMap() {return _testMap;}
>>>>> }
>>>>>
>>>>>
>>>>> void main()
>>>>> {
>>>>> Test test = new Test();
>>>>> test.testMap[0] = 1;
>>>>> }
>>>>> /////////////////
>>>>>
>>>>> *** Error: test.testMap() is not an lvalue
>>>>>
>>>>>
>>>>> Regards,
>>>>> flourish
>>>>>
>>>>>
>>>>>
>>>
>