January 25, 2013
On Thu, 24 Jan 2013 23:36:30 +0400
Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
> 
> These days properties imply an action of, well, obtaining said value. If it's a wrapper as in "return zis variable" something is wrong already.
> 

I agree in principle, but unfortunately "return zis variable" getters are often needed because no major language (that I know of) offers any other way to create data that's privately-writable and publicly-read-only - a very common need.

Ie, that's the "something" that "is wrong already": the lack of a simple built-in "The public can only read this, but I can R/W it." to obviate an extremely common idiom.

January 25, 2013
25-Jan-2013 23:27, Nick Sabalausky пишет:
> On Thu, 24 Jan 2013 23:36:30 +0400
> Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
>>
>> These days properties imply an action of, well, obtaining said value.
>> If it's a wrapper as in "return zis variable" something is wrong
>> already.
>>
>
> I agree in principle, but unfortunately "return zis variable" getters
> are often needed because no major language (that I know of) offers any
> other way to create data that's privately-writable and
> publicly-read-only - a very common need.
>
> Ie, that's the "something" that "is wrong already": the lack of a
> simple built-in "The public can only read this, but I can R/W it." to
> obviate an extremely common idiom.

It might be worth extending the access modifiers (not going to happen) or maybe simplifying the boilerplate... (could happen but dunno).

-- 
Dmitry Olshansky
January 26, 2013
On 2013-01-25 20:27, Nick Sabalausky wrote:

> I agree in principle, but unfortunately "return zis variable" getters
> are often needed because no major language (that I know of) offers any
> other way to create data that's privately-writable and
> publicly-read-only - a very common need.
>
> Ie, that's the "something" that "is wrong already": the lack of a
> simple built-in "The public can only read this, but I can R/W it." to
> obviate an extremely common idiom.

In Ruby one would do:

class Foo
  attr_reader :foo
end

This would create a getter and an instance variable. Internally one can write directly do the instance variable, or create a setter:

class Foo
  attr_reader :foo

private

  def foo= (value)
    # code
  end
end

The equal sign indicates the method is a property. Not that "attr_reader" is not a language feature, it's implemented in the core library. There are also functions available for getter and both getter and setter.

In D, I would like to see something like this:

@property(get, set) int a;
@property(get) int b;
@property(set) int c;
@property int d; // same as "a"

This would create a getter and/or setter and an instance variable. One could also experiment with the protection attributes like this:

public @property(get, protected set) int a;

One way could affect the instance variable, the other way to affect the getter/setter implementation.

-- 
/Jacob Carlborg
January 26, 2013
On Sat, 26 Jan 2013 12:33:11 +0100
Jacob Carlborg <doob@me.com> wrote:

> On 2013-01-25 20:27, Nick Sabalausky wrote:
> 
> > I agree in principle, but unfortunately "return zis variable" getters are often needed because no major language (that I know of) offers any other way to create data that's privately-writable and publicly-read-only - a very common need.
> >
> > Ie, that's the "something" that "is wrong already": the lack of a simple built-in "The public can only read this, but I can R/W it." to obviate an extremely common idiom.
> 
> In Ruby one would do:
> 
> class Foo
>    attr_reader :foo
> end
> 
> This would create a getter and an instance variable. Internally one can write directly do the instance variable, or create a setter:
> 
> class Foo
>    attr_reader :foo
> 
> private
> 
>    def foo= (value)
>      # code
>    end
> end
> 
> The equal sign indicates the method is a property. Not that "attr_reader" is not a language feature, it's implemented in the core library. There are also functions available for getter and both getter and setter.
> 
> In D, I would like to see something like this:
> 
> @property(get, set) int a;
> @property(get) int b;
> @property(set) int c;
> @property int d; // same as "a"
> 
> This would create a getter and/or setter and an instance variable. One could also experiment with the protection attributes like this:
> 
> public @property(get, protected set) int a;
> 
> One way could affect the instance variable, the other way to affect the getter/setter implementation.
> 

Interesting.

Although with that in mind it seems my earlier statement is not entirely true. There are languages that offer a "publically read-only" feature: C# and Haxe. I think it just didn't occur to me because they do it via shorthand versions of their property syntaxes.

January 26, 2013
On 2013-01-26 19:55, Nick Sabalausky wrote:

> Interesting.
>
> Although with that in mind it seems my earlier statement is not
> entirely true. There are languages that offer a "publically read-only"
> feature: C# and Haxe. I think it just didn't occur to me because they
> do it via shorthand versions of their property syntaxes.

Depending on how you look at it, D1 with const variables does as well and Java with final variables.

-- 
/Jacob Carlborg
3 4 5 6 7 8 9 10 11 12 13
Next ›   Last »