Nice TWiki > Dev > FeatureProposals > PropertySyntax (r1.3) 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

In my experience, I have found that protected fields have the same problems as public fields in classes. That is, once you set a field as protected, you are no longer able to control access to the fields by subtypes. What I would like to see in the language would be that all fields default as private. If the user wants to make a field protected or public he would override the method with their implementation. An example:

class PropertySyntax{
     String property1;

would be transformed by the compiler to:

class PropertySyntax{
     private String property1;
     private String property1();//the get method
     private void property1(String property1);// the set method
//default get implementation
   return syntax.property1;
//default set implementation
Now if the user provides their own methods to the class then those methods should be used instead of the default ones. So lets say I want to make the get method public and change the implementation of the set method but keep it private.
class PropertySyntax{
    String property1;
    public property1();
//since I have not specifed an implementation of property1(); the compiler will auto-generate the method but with public access instead.
property1(syntax,property1){//no need to declare this in the class since the signature is assumed by default
   super;//call the super classes version. Or in the case of private or base class use the default version
   //do stuff

now when the user of the class wants to get the field they should be able to do it 2 ways:

PropertySyntax syntax=new  PropertySyntax(value);
//method syntax
//or the can use field syntax
//althought the example above does not allow setting. if it did you would have the following
//method syntax
//field syntax
The advantage to the above approach is the following:
  1. no need to change the syntax of the language.
  2. enforces good OO practices by keeping fields private.
  3. Field syntax makes it as easy to set fields as it would be if the field were public.

Thoughts and questions welcome.

ArthurSmyles 23 Mar 2003

Topic PropertySyntax . { Edit | Attach | Ref-By | Printable | Diffs | r1.8 | > | r1.7 | > | r1.6 | More }
Revision r1.3 - 10 Apr 2003 - 21:19 GMT - ArthurSmyles
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.