ooc-dev team mailing list archive

[Alec Benzer <alecbenzer@xxxxxxxxx>]

I thought of that, but that seemed a bit silly too. Ie, isn't the whole
point of virtual properties to allow the user to access what looks
syntactically like instance data, but in fact isn't. Though here,
there *is* instance
data we could be directly accessing.

And wouldn't it still be possible to have virtual properties even with
allowing direct access outside the getter/setter. For example, ruby doesn't
have properties per se, but it basically does with methods like *varname* and
*varname=*. So, in ruby, if you have an instance member with appropriate
getters/setters, you can access it using them (ie, x = 5 ; foo = x*2), or,
you can access the instance data directly (@x = 5 ; foo = @x*2 ). Nothing
stops you from writing "virtual property" methods like foo= and foo, even if
there is no actual @foo data member.

So wouldn't it be possible to do have some syntax that allows you direct
access to a property's underlying instance data directly, failing if the
property is virtual?

On Sun, Sep 26, 2010 at 12:34 PM, Friedrich Weber <
fred.reichbier@xxxxxxxxxxxxxx> wrote:

> Hey Alec,
>
>
>  I thought this would work, but then I realized that it resulted in an
>> infinite recursion. Since normalize assigns to numerator and denominator,
>> this invokes the property setter which in turn runs normalize().
>>
>
> Yep, you're right about that. You could work around it by normalizing the
> fraction *inside* the setter (because writing accesses won't get replaced by
> setter calls here), but that would lead to code duplication, and we hate
> code duplication. :p
>
> Another working solution is: Make `numerator` and `denominator` *virtual*
> properties that work with an (private-by-convention) attribute. Like this:
>
>    Fraction : class {
>
>        _numerator: Int
>        numerator: Int {
>            get {
>                _numerator
>            }
>            set(n) {
>                _numerator = n
>                normalize()
>            }
>        }
>
>        _denominator: Int
>        denominator: Int {
>            get {
>                _denominator
>
>            }
>            set(d) {
>                if(d != 0) {
>                    _denominator = d
>                    normalize()
>                }
>            }
>        }
>
>        init: func (=numerator, =denominator) {}
>
>        normalize: func {
>            "normalize()" println()
>            gcd := this gcd()
>            if(gcd != 0) {
>                _numerator /= gcd
>                _denominator /= gcd
>            }
>        }
>
>        gcd: func -> Int {
>            (a,b) := (this _numerator, this _denominator)
>            while(b != 0) {
>                t := b
>                b = a % b
>                a = t
>            }
>            a
>        }
>    }
>
>    main: func {
>      f := Fraction new(4, 5)
>      f denominator = 8
>      "%d/%d" printfln(f numerator, f denominator)
>    }
>
> `normalize` manipulates `_numerator`/`_denominator` here - they aren't
> properties, so they don't cause recursion.
>
> Well okay, it still *looks* like a workaround, but i think it isn't - it
> would be done similarly in Python, for example. The advantage of our current
> approach (allow direct access only inside the getter/setter) is: We can do
> virtual properties: Properties that don't have a real value in the object
> struct. This is useful for wrapping C getter/setter functions to cover
> properties.
>
> Hope that helps,
>
> Friedrich
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ooc-dev
> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ooc-dev
> More help   : https://help.launchpad.net/ListHelp
>