On Wednesday, 30 January 2013 at 20:28:32 UTC, Jacob Carlborg wrote:
> Sure, but I think that's what properties are for. We currently don't have that in D but I think it would be great if fields could be exchanged with methods without breaking the API.

The problem is that genie is out of the bottle once you have committed yourself to an interface where there is a public member variable. And you can't put the genie back in the bottle any more. This means that your interface can't add any encapsulation over this public member variable afterwards without changing the interface.

As interface api good practice is usage virtual public functions of classes.
So, (virtual) properties add an additional usefulness.

On Wednesday, 30 January 2013 at 21:07:56 UTC, TommiT wrote:
> The problem is that genie is out of the bottle once you have committed yourself to an interface where there is a public member variable. And you can't put the genie back in the bottle any more. This means that your interface can't add any encapsulation over this public member variable afterwards without changing the interface.

A bit more code, a bit less metaphors:

struct S
{
    T data;
}

// end-user code:

S s;
*&s.data = 42;

End-user thus by-passes any encapsulation that could be possible added over S.data field later on, like the following:

struct S
{
    private T _data;

    @property ref T data() { return _data; }

    @property ref T data(int v)
    {
        assert(v != 42);
        _data = v;
        return _data;
    }
}

On 01/30/2013 09:10 AM, Jacob Carlborg wrote:
> On 2013-01-30 02:40, TommiT wrote:
>
>> I always thought that having public member variables is a bad style of
>> programming because of the lack of encapsulation. So, if there's a
>> language feature that enables you to write public member variables, and
>> later on, replace them with property functions, wouldn't that mean that
>> the language is encouraging this particular kind of bad style of
>> programming?
>
> I really don't see much point in properties/methods that just forwards
> to an instance variable.
>

Me either.

I mean yes, for anything that is part of a public api you should probably double check everything.  But insisting on getters and setters regardless of the requirements of what you are getting and setting?

Sounds like an excuse to not think, to me.

On Wednesday, 30 January 2013 at 21:26:34 UTC, 1100110 wrote:
> Me either.
>
> I mean yes, for anything that is part of a public api you should probably double check everything.  But insisting on getters and setters regardless of the requirements of what you are getting and setting?
>
> Sounds like an excuse to not think, to me.

Putting in public variables sounds like not thinking, to me. Interface should expose the minimum amount of access possible, whereas public variables expose the maximum amount of access.

On Wednesday, January 30, 2013 15:26:32 1100110 wrote:
> On 01/30/2013 09:10 AM, Jacob Carlborg wrote:
> > On 2013-01-30 02:40, TommiT wrote:
> >> I always thought that having public member variables is a bad style of programming because of the lack of encapsulation. So, if there's a language feature that enables you to write public member variables, and later on, replace them with property functions, wouldn't that mean that the language is encouraging this particular kind of bad style of programming?
> > 
> > I really don't see much point in properties/methods that just forwards to an instance variable.
> 
> Me either.
> 
> I mean yes, for anything that is part of a public api you should probably double check everything. But insisting on getters and setters regardless of the requirements of what you are getting and setting?
> 
> Sounds like an excuse to not think, to me.

The main reason for it is that you can add additional code later when it no longer needs to just get or set the variable. But one of the goals of properties is to make it so that you can just make it a public variable to begin with and then swap it out with a property function later when you need to add code like that. However, that never quite seems to work perfectly, as there's always something that you can do with a variable that you can't do with a property function (e.g. take its address or pass it by ref). Without properties though, you definitely want the getters and setters so that you don't lock yourself out of being able to properly protect the variable when you actually need to later.

- Jonathan m Davis

On Wednesday, 30 January 2013 at 00:25:41 UTC, Jonathan M Davis wrote:
> 1. Make it possible to Mark a variable such that you can't do anything with it that you couldn't do with a property function (e.g. taking its address needs to be illegal).

 If we didn't have to interface with C and we were willing to get a little extra processing in order to use flags you could get away with this. In a 64Bit environment it seems plausible.

 I don't see this as an option realistically with everything as it is, however the potential can't be ignored.

 Let's say the top 4 bits of a pointer are flags, one for 'is stack' and one for 'is function ptr', etc. The function pointer referenced then then make properties work exactly like variables.

 Mind you likely a few extra flags may be needed to determine constness for safety, or two ptrs for a getter/setter (or just a small lookup table for a combination of them all).

 If these flags then are used and recognize that it has a function instead of a variable, it can call the function, however passing to C or anything expecting a variable then it would have to throw an error as there's no way for the D specific flags to be carried over and used safely.

  struct S {
    int _a;
    int a() {return a + 1;}
    int a(int setA) { _a = setA; return setA; }
  }

  Now:

  void func(ref int a) {
    a = 100;
    //real int always passes
    assert(a == 100);
    //can't assume true with function property pointer
  }

  S s;

  //passes, flag realizes it's a function that now is
  //treated as a variable for this purpose.
  func(s.a);

  extern(C) void cFunction(int *ptr);

  //fails, C unaware of handling function reference
  cFunction(s.a);
  //fails, same reason.
  cFunction(&s.a);

 Perhaps it's a small option that in compiling these flags can be made use of; Instantiation of templates the properties can be treated as variables correctly (invisibly), assuming it never passes a reference to anything it can't verify can handle it.

 But as before, this is just an idea, which won't be used in D.

On Tue, 29 Jan 2013 18:09:44 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Tuesday, January 29, 2013 12:10:04 Steven Schveighoffer wrote:
>> Sound crazy? Ridiculous? Impossible? Insulting?
>
> It seems like it could work, but without a way to explictly make something a
> getter property, it will be impossible to change a property function into a
> variable later without risking breaking code, because then people will still
> be able to call the property function with parens. Using parens on getter
> properties has to be illegal for that to work.

I don't think this is quite right.

You can never *exactly* replace a field with a property, or vice versa.  There are aspects that are different for both.

But there are two separate cases here.  One is, you define a property that is specific to a type, and then replace it with a field.  The other is that there is a DEFINED API, and you replace it with a field.

In the first case, yes, you would have to go through and replace () instances with ones that do not have it.  If your documentation is clear, then it really is on the user to have made that mistake.  With the idea I specified later where getX would require no parentheses, you could specify a property that could not be called like a function unless you use the getX version.

But in the second case, consider for instance a range.  A range has an empty field/property.  If you called it via empty(), then your code is broken for all different types of ranges which use a field (or enum).

In any case, I think there is no getting around that changing from a property to a field or vice versa will cause problems for existing code.

-Steve

On Tue, 29 Jan 2013 19:26:09 -0500, q66 <quaker66@gmail.com> wrote:

> It deeply disturbs me that people even take the original post seriously.

Sorry it offends you, but maybe you could have a constructive comment instead of a condescending tone?  This is not a frivolous proposal, and it's not my first, but I'm trying to fit something with the language designers who have expressed a significant distaste with @property to the point where they just want to go back to the crap we had before.  If we can get ANY kind of property syntax, I think it's better than that.

-Steve

On Wed, 30 Jan 2013 03:05:37 -0500, q66 <quaker66@gmail.com> wrote:

> On Wednesday, 30 January 2013 at 03:02:38 UTC, deadalnix wrote:
>> On Wednesday, 30 January 2013 at 00:26:11 UTC, q66 wrote:
>>> It deeply disturbs me that people even take the original post seriously.
>>
>> Well, you may give some arguments instead of no, just no, to convince people.
>
> It just gives another meaning to foo.bar, and ENFORCING camelCase by the language while lowercasing shit is just horrible. Anyone with a slightest trace of language design sense realizes that.

Apparently not the designers of objective-C.

-Steve