Nice TWiki > Dev > FeatureProposals > PropertySyntax 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{
     private String property1;

would be transformed by the compiler to:

class PropertySyntax{
     private String priv_property1;//this variable would not be reachable by the user of the language. If the user wants to set or get the value, they need to use the methods provided
     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{
    private 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

I think a decision about this should be taken soon since details of others things like constructors depend on this.

-- ArjanB - 03 Jun 2003

Could you describe how they depend on this? What would be the consequences?

-- DanielBonniot - 04 Jun 2003

I don't know what's been decided on this, if anything. But I'm generally in favor of the ideas propsoed above, especially those by ArthurSmyles. I like the C# solution, though I'm not stuck on the syntax. The goal is that all code outside of a class should not know or care if a member is implemented directly accessible, or hidden behind a method or methods. That allows for the greatest degree of refactoring by the class implementor in the future, by lowering the degree coupling, which is always a good thing in large projects.

-- TroyHeninger - 12 Nov 2003

What is holding this back is mostly the lack of manpower. We will get to implementing it eventually, but the more people are willing to contribute, the faster things will move. Would you be interested in helping (with this or another aspect)?

-- DanielBonniot

Topic PropertySyntax . { Edit | Attach | Ref-By | Printable | Diffs | r1.8 | > | r1.7 | > | r1.6 | More }
Revision r1.8 - 12 Nov 2003 - 21:24 GMT - DanielBonniot
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.