Nice TWiki > Dev > FeatureProposals > PropertySyntax (r1.1) TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Dev . { Changes | Index | Search | Go }
I was thinking if it maybe would be a good idea to let the compiler help when writing properties. What if we could let the compiler automatically create get/set functions in the same fashion it does with the automatic constructor ?

Of course it is not sufficient to generate get AND set all the time, but we could use keywords like

We could then declare fields like:

class Test
  private read String someString;
  private readwrite int someInt;
and then be able to call getSomeString() but NOT setSomeString(s) (the compiler knows that set is not defined since someString is only read'able)

Another idea (I like even better) would be to then be able to write

Test t = new Test
 (someString: "Test"
  someInt: 3
//but NOT
//t.someString = "AnotherTest";
A problem that I see with automatic generation of this methods (operators) is that there should be a way to override them ! This makes me think of the way C# handles properties (very nice I think)

in C# you can write:

class PluggableContainer
  private SystemState state;

  public SystemState State
      // found no actives and no inactives at the beginning
      bool foundActive = false;
      bool foundInactive = false;
      // loop through all IPluggable objects
      foreach(IPluggable pluggable in items)
        if(pluggable.Active) foundActive = true;
        else foundInactive = true;

      // try all possible combinations
      if(foundActive && foundInactive) this.state = SystemState.PartlyActive;
      if(foundActive && !foundInactive) this.state = SystemState.Active;
      if(!foundActive && foundInactive) this.state = SystemState.Inactive;
      if(!foundActive && !foundInactive) this.state = Systemstate.Error;

      return state;
      if(value == SystemState.Active) SetState(true);
      if(value == SystemState.Inactive) SetState(false);
value is implicitely generated and contains the value to set (always the same type as the field)

So what about a combination of these ideas ? we could generate the methods with default behaviour, if more special instructions are needed we could override them.

The compiler could then (somehow:-) know that when he sees a Person.getName method he can also use String s = but not = "gamsl" since he knows no setName method ...

Knowing nothing about compilers and language design in general .... what do you guys think :-)???

-- GamsL - 20 Jul 2002

Topic PropertySyntax . { Edit | Attach | Ref-By | Printable | Diffs | r1.8 | > | r1.7 | > | r1.6 | More }
Revision r1.1 - 30 Jan 2003 - 00:45 GMT - TWikiGuest
Parents: WebHome > FeatureProposals
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.