Idea: Variables enclosed by properties

[Charles]

Sometimes I would like to ensure that an object variable is not accessed other than through its corresponding property. In other words, I don't want methods(*) to access the variable, except through that property. Here is the idea:

class Example

    pro name as String
        var _name  # <-- var decl *inside* a property. type is assumed to match the property
        get
            return _name
        set
            _name = value.trim

    def foo
        _name = 'foo'  # error: Variable _name is enclosed by property; use .name instead.

(*) or other code members such as properties and indexers

Reactions?

[Charles]

Oh, and if you needed multiple vars, no problem. And you can explicitly state the return type of each.

[relez]

why not? I see no contraindication at a first glance.... one question: in your example _name lives and dies "in the pro". But outside can another "_name" exist? that is, is the following code legal?

Code: Select all

class Example   
    var _name as whatelse
    pro name as String      
        var _name 
............

[Charles]

The enclosed variable's lifetime is the lifetime of the object. Its *scope* is what is bound to the property

Regarding having another _name outside the property, I think that's a bad idea and should be an error.

Furthermore, I was thinking this feature could be generalized like so:

class Example

    var _foo as String
        has VisibleTo('foo', 'bar')

    pro foo as String
        get
            return _foo
        set
            _foo = value.trim

    def bar
        _foo = ''

    def baz
        print _foo  # error
        _foo = ''  # error

Should initializers be given implied access to any and all variables?

So declaring a var inside a property is just a shortcut syntax for a normal var declaration with a VisibleTo() attribute. You would use the attribute if you wanted to grant access to multiple members or if you preferred to keep all your var declarations together.

[relez]

The enclosed variable's lifetime is the lifetime of the object. Its *scope* is what is bound to the property

Regarding having another _name outside the property, I think that's a bad idea and should be an error.

Yes, i agree

Furthermore, I was thinking this feature could be generalized like so:

class Example

    var _foo as String
        has VisibleTo('foo', 'bar')

    pro foo as String
        get
            return _foo
        set
            _foo = value.trim

    def bar
        _foo = ''

    def baz
        print _foo  # error
        _foo = ''  # error

Should initializers be given implied access to any and all variables?

So declaring a var inside a property is just a shortcut syntax for a normal var declaration with a VisibleTo() attribute. You would use the attribute if you wanted to grant access to multiple members or if you preferred to keep all your var declarations together.

Ok, nice this way.

[relez]

I come back on this idea after a short playing with it.... Now i'm not sure it's a good feature. Of course it could be useful as i can use it to reduce code... but on the other side i like a program when i can easilly read it... i'm a bit confused on this... in general, i don't like that there are two ways to solve such a simple task. VisibleTo is clear and simple and less bug prone (i believe) also if compiler could help on this. To explain the concept I appreciate Guido's idea about Python 3.0: “There should be one—and preferably only one—obvious way to do it”.
In short terms i don't see many advantages.... Oh, this is only my point of view

[Charles]

In Python 3.0, I think it's still the case that you can use map(), "for" in expressions or a "for" statement. All three are legit ways to process a list... I don't know if Guido considers one of them to be "obvious", or if the "obvious choice" changes depending on what you're doing.

Regarding Cobra declarations, the convention is to use the succinct form over the less succinct form. A current example, would be a read only property:

class X

    get text as String
        return _text ? ''

    pro text as String
        get
            return _text ? ''

Both are valid declarations, but the first form is more succinct and is chosen by that convention.

HTH

[relez]

Yes, i don't know if Python 3.0 really always realizes what Guido says, i devoted too short time about the incoming version of Python, but i like the idea in itself. obviously there is nothing wrong in implementing alternative methods to perform certain tasks as your sample shows.
Tk u.

[jonathandavid]

Sometimes I would like to ensure that an object variable is not accessed other than through its corresponding property. In other words, I don't want methods(*) to access the variable, except through that property. Here is the idea:

class Example
    pro name as String
        var _name  # <-- var decl *inside* a property. type is assumed to match the property
        get
            return _name
        set
            _name = value.trim

    def foo
        _name = 'foo'  # error: Variable _name is enclosed by property; use .name instead.

(*) or other code members such as properties and indexers

Reactions?

This is a fantastic idea, let's have it. My only concern is that the inner variable name remains preceded by an underscore, when it is clearly not protected in the sense that regular object variables are protected. I guess can live with that, provided that we grant derived classes that override the property access to the inner variable. E.g.:

class Foo
     pro bar as int
          var _bar = 0
          get
                return _bar
          set 
                _bar = value
       

class Derived

     pro bar as int is override
          get
                return _bar * 2   # has access
          set 
                _bar = value / 2   # ditto

Of course, Derived would not have access to the inner var had it been defined with two leading underscores (i.e., private). I guess you had already thought about that, but I just wanted to make sure.

You suggest that we will be allowed to define several inner variables for each property, each with its own type. If that is the case, then I suggest that we force the inner variable's type to be specified even when it coincides with that of the property. E.g., in your initial example, we would be forced to write "var _name as String" instead of simply "var _name". The reason is that to me it would be ugly to see something like:

class Foo
        pro name as String
                var _x as int   
                var _foo                 # as what?? it's not so obvious that it should be String if it's no longer named as the property
                get
                        return _foo * _x
                set
                _foo = value / _x

If we really want to avoid typing the type of the property twice, then I suggest a more readable syntax shortcut

class Foo
      pro bar as int
          var _bar as pro       # int
          get
                return _bar
          set 
                _bar = value

class Example
     var _foo as String
         has VisibleTo('foo', 'bar')

I would vote against this, IMHO it looks like a needless complication, and it will make code less readable. I would hate to have to read code written by someone else that makes heavy use of this feature.

[jonathandavid]

Another idea:

class Foo
      pro bar from inner var as int

This would be equivalent to

class Foo
      pro bar as int
          var _bar as int
          get
                  return _bar
          set 
                  _bar = value