www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - AA as lvalue

reply "John C" <johnch_atms hotmail.com> writes:
Is there any reason why the following code shouldn't compile?

public class ColorTable {

  public Color buttonBorder() {
    return namedColorTable[NamedColors.BUTTONBORDER];  // error here: 
this.namedColorTable() is not an lvalue
  }

  private enum NamedColors {
    BUTTONBORDER,
    BUTTONHIGHLIGHT
    // ... etc ...
  }

  private void initNormalColors() {
    namedColorTable_[NamedColors.BUTTONBORDER] = SystemColors.highlight;
    // ... etc ...
  }

  private Color[NamedColors] namedColorTable() {
    if (namedColorTable_ is null)
      initNormalColors();
    return namedColorTable_;
  }

  private Color[NamedColors] namedColorTable_;

}

If I change the buttonBorder() property to directly use namedColorTable_ 
instead of calling through the namedColorTable() property (and do 
initNormalColors() in the constructor) it compiles. The reason why I haven't 
done it that way is because I want namedColorTable() to handle Windows 
visual styles, perhaps like this:

    private Color[NamedColors] namedColorTable() {
        if (namedColorTable_ is null) {
            if (VisualStyleInfo.enabled) {
                if (VisualStyleInfo.colorScheme == "NormalColor")
                    initNormalColors();
                else if (VisualStyleInfo.colorScheme == "HomeStead")
                    initOliveColors();
                else if (VisualStyleInfo.colorScheme == "Metallic")
                    initSilverColors();
            }
            else
                initSystemColors();
        }
        return namedColorTable_;
    }

And namedColorTable_ would get reset to null when the user changes their 
preferences, meaning the color schemes get reinitialised when 
namedColorTable() is next called. Granted, people don't change their desktop 
colors that often, but they do on occasion, and an application should 
probably sync up with those changes if they happen while it's running. Any 
ideas?

John. 
Mar 31 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 31 Mar 2005 11:54:27 +0100, John C <johnch_atms hotmail.com> wrote:
 Is there any reason why the following code shouldn't compile?

I can't think of any. Regan
Mar 31 2005
prev sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"John C" <johnch_atms hotmail.com> wrote in message 
news:d2gktk$mbk$1 digitaldaemon.com...
 Is there any reason why the following code shouldn't compile?

 public class ColorTable {

  public Color buttonBorder() {
    return namedColorTable[NamedColors.BUTTONBORDER];  // error here: 
 this.namedColorTable() is not an lvalue
  }

It might be easiest to change things around a little and use namedColorTable_ instead of the property namedColorTable and an lvalue ColorTable. Maybe this is a compiler bug with properties - I don't know. Sometimes I can't tell when the compiler needs () and when it doesn't. What I'm thinking: public Color buttonBorder() { ColorTable ct = namedColorTable;// needs ()? I haven'te tried it return ct[NamedColors.BUTTONBORDER]; // will insert if not present so it needs an lvalue } or public Color buttonBorder() { validateColorTable(); return namedColorTable_[NamedColors.BUTTONBORDER]; }
Mar 31 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 public Color buttonBorder() {
  ColorTable ct = namedColorTable;// needs ()? I haven'te tried it

oops- that should be Color[NamedColors] ct = namedColorTable;
Mar 31 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:d2grh8$t9f$1 digitaldaemon.com...
 public Color buttonBorder() {
  ColorTable ct = namedColorTable;// needs ()? I haven'te tried it


So far as I can tell, most cases where you needed to add () to access a property have been eliminated.
 oops- that should be Color[NamedColors] ct = namedColorTable;

Thanks, Ben. That did the trick.
Mar 31 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 oops- that should be Color[NamedColors] ct = namedColorTable;

Thanks, Ben. That did the trick.

note you could also switch to using a dynamic array instead of an associative array and then namedColorTable could be used as an lvalue (plus it would be faster and simpler).
Mar 31 2005
parent "John C" <johnch_atms hotmail.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:d2h29r$14ss$1 digitaldaemon.com...
 oops- that should be Color[NamedColors] ct = namedColorTable;

Thanks, Ben. That did the trick.

note you could also switch to using a dynamic array instead of an associative array and then namedColorTable could be used as an lvalue (plus it would be faster and simpler).

Exactly the conclusion I came to - I redesigned the class using a dynamic array, since the key values for the AA were basically indexes anyway.
Mar 31 2005