On 06/30/2013 08:54 PM, JS wrote:

> On Monday, 1 July 2013 at 02:17:24 UTC, Ali Çehreli wrote:

>> I have the complete opposite view: Seeing what m_data explicitly in
>> the code would be simpler than reading code to see that data.value
>> would mean implicit storage.
>>
>
> huh? There is absolutely no semantic difference between the two.

Agreed. I find implicit storage making code more complex.

> The
> proposed case is easier because the field can't be hidden away somewhere
> making it hard to find.
>
> @property T x() { }
>
> represents a function and possibly a variable of type T. You know that
> by looking at the property. It is not a hard leap to understand.

Agreed but I was talking about understanding the implementation, not the API. When a function returns data.value, it returns the 'value' member of a variable 'data'. Where is 'data'? Not a local variable. Not a member? A global? Oh! I wonder? Yes, it is an implicit member that is created by the compiler.

Note the old proposal that Jonathan has reminded us about does not have that problem. It is obvious that we are looking at a property.

>
> The old way:
>
> @property T x() { }
> T _x;
>
> Is more verbose, and verbose is not always better.

Agreed in general but not in this case.

> If your class as many
> variables and some are hidden then it could be difficult to know where
> the variable is.

That is always possible and requires discipline and coding guidelines. The programmers must know to communicate ideas and designs.

> It's no different than writing separate setters and getters... no
> difference... just they are more verbose. If you are against my
> suggestion you should be against properties in general because they are
> a simplification of such.

I am not against how they make syntax easier. I don't need to prefix function names by get_ or set_ and I don't need to use parentheses.

>> > (if propertyname.value is used then
>> > there needs to be an internal variable, else not),
>>
>> Where would the compiler make room for that variable in relation to
>> the other members? With programming languages, explicit is almost
>> always better than implicit.
>>
>> Ali
>
> huh? The exact same place it does so if the programmer explicitly adds
> it.

How can the compiler put it in *the exact spot* if I am not adding it explicitly? Are you suggesting that such functions be inserted between other member variables?

struct Foo
{
    int m;
    @property int data() { return data.value; } // read property
    @property int data(int value) { return data.value; } // write property
    double d;
}

What if there is another member between these special functions? Compiler error?

> It's location in the class my not be the same but that is, in
> general, irrelevant unless you are messing with the bits of the class.

I was thinking about structs.

Ali

On Monday, 1 July 2013 at 16:24:40 UTC, Ali Çehreli wrote:
> On 06/30/2013 08:54 PM, JS wrote:
>
> > On Monday, 1 July 2013 at 02:17:24 UTC, Ali Çehreli wrote:
>
> >> I have the complete opposite view: Seeing what m_data
> explicitly in
> >> the code would be simpler than reading code to see that
> data.value
> >> would mean implicit storage.
> >>
> >
> > huh? There is absolutely no semantic difference between the
> two.
>
> Agreed. I find implicit storage making code more complex.

(Well, I'm sure some will find it useful in some cases and I don't think such a case could hurt much but I'd probably never use it)

>
> > The
> > proposed case is easier because the field can't be hidden
> away somewhere
> > making it hard to find.
> >
> > @property T x() { }
> >
> > represents a function and possibly a variable of type T. You
> know that
> > by looking at the property. It is not a hard leap to
> understand.
>
> Agreed but I was talking about understanding the implementation, not the API. When a function returns data.value, it returns the 'value' member of a variable 'data'. Where is 'data'? Not a local variable. Not a member? A global? Oh! I wonder? Yes, it is an implicit member that is created by the compiler.
>
> Note the old proposal that Jonathan has reminded us about does not have that problem. It is obvious that we are looking at a property.
>

Well, I personally don't care what symbols or syntax you want to use(well, within reason). I used a common syntax because it is something people are familiar with. To me it is nitpicking because it has nothing to do with the real issue. It's not the syntax that is under question but the concept/implementation.

What's important to me is to not have to create a private field every time I want to create a property. It seems like a waste of time and is verbose for no reason. It doesn't confuse me one bit to "hide" the field in the property because essentially that's what properties do(to the user of the property)... So it doesn't change anything from the outside and only goes to reduce your code size.

> >
> > The old way:
> >
> > @property T x() { }
> > T _x;
> >
> > Is more verbose, and verbose is not always better.
>
> Agreed in general but not in this case.
>
> > If your class as many
> > variables and some are hidden then it could be difficult to
> know where
> > the variable is.
>
> That is always possible and requires discipline and coding guidelines. The programmers must know to communicate ideas and designs.
>

Yes, but any programming language is there to simplify... If we had infinite memories and intelligence then direct machine language(hex) would be just fine.

IMO by removing excess and essentially useless text in source code makes it easier to follow and maintain. Almost all programming constructs do this... sometimes it's their sole purpose(a macro, function, struct, etc...). (encapsulation of data/code is mainly to simplify complexity and not for security/safety)

> > It's no different than writing separate setters and
> getters... no
> > difference... just they are more verbose. If you are against
> my
> > suggestion you should be against properties in general
> because they are
> > a simplification of such.
>
> I am not against how they make syntax easier. I don't need to prefix function names by get_ or set_ and I don't need to use parentheses.
>
> >> > (if propertyname.value is used then
> >> > there needs to be an internal variable, else not),
> >>
> >> Where would the compiler make room for that variable in
> relation to
> >> the other members? With programming languages, explicit is
> almost
> >> always better than implicit.
> >>
> >> Ali
> >
> > huh? The exact same place it does so if the programmer
> explicitly adds
> > it.
>
> How can the compiler put it in *the exact spot* if I am not adding it explicitly? Are you suggesting that such functions be inserted between other member variables?

I'm not sure we are are talking about the same thing:

> struct Foo
> {
>     int m;
>     @property int data() { return data.value; } // read property
>     @property int data(int value) { return data.value; } // write property
>     double d;
> }
>
> What if there is another member between these special functions? Compiler error?
>
> > It's location in the class my not be the same but that is, in
> > general, irrelevant unless you are messing with the bits of
> the class.
>
> I was thinking about structs.
>
> Ali


struct Foo
{
    // int data.value; "inserted here"
    int m;
    // int data.value; or here
    @property int data() { return data.value; } // read property
    // int data.value; or here
@property int data(int value) { return data.value = value; } // write property
    // int data.value; or here
    double d;
    // int data.value; or here

}

vs

struct Foo
{
    int m;
    @property int data() { return val; } // read property
    @property int data(int value) { return val = value; } // write property
    double d;
    private int val;
}


It will almost never matter where the compiler inserts the hidden variable for us except when "hacking" the struct(which, as long as it's consistent, it shouldn't matter.

to me, the first case is more concise but does EXACTLY the same thing. I like things to be concise. I don't wanna see crap that I don't need to see. In the 2nd case, val is only required because the compiler is not smart enough. We can easily write a preprocessor to do the above(in fact, I've done it before).

>>
>> > It's location in the class my not be the same but that is, in
>> > general, irrelevant unless you are messing with the bits of
>> the class.
>>

Actually we do this a lot in C++ where I work to ensure proper alignment. We are also starting to do this in D where we have C++ <-> D bindings so we can make our D structs exactly match our C++ structs in memory.

Personally I see less benefit over:

public @property int value;

This approach is nice. It can be used both when layout is important and when it is "don't care" and is clearer. I can look at the struct and immediately read its memory footprint.

Your suggested proposal cannot be used when layout is important as it is left to the compiler. It would require a workaround to coerce the compiler into submission, or additional compiler circuitry making it even more complex and slowing it down.

On Tuesday, 2 July 2013 at 04:49:55 UTC, estew wrote:
>>>
>>> > It's location in the class my not be the same but that is, in
>>> > general, irrelevant unless you are messing with the bits of
>>> the class.
>>>
>
> Actually we do this a lot in C++ where I work to ensure proper alignment. We are also starting to do this in D where we have C++ <-> D bindings so we can make our D structs exactly match our C++ structs in memory.
>
> Personally I see less benefit over:
>
> public @property int value;
>
> This approach is nice. It can be used both when layout is important and when it is "don't care" and is clearer. I can look at the struct and immediately read its memory footprint.
>
> Your suggested proposal cannot be used when layout is important as it is left to the compiler. It would require a workaround to coerce the compiler into submission, or additional compiler circuitry making it even more complex and slowing it down.

Or just use the old way. Just because one extends a feature does not mean the old feature is removed. If you need to hack up the bits just explicitly allocate the field... simple as that.

On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:
>
> I believe that the way that this sort of enhancement has typically been
> suggested is to do something like
>
> public @property int value;
>
> which would be lowered to something like
>
> public @property int value() @safe const pure nothrow { return _value; }
> public @property int value(int v) @safe pure nothrow { return _value = v; }
> private int _value;
>
> - Jonathan M Davis

As someone who uses properties almost everywhere, and almost never uses public fields, this is one of my biggest gripes with D remaining. It's incredibly annoying to have to do things like

private int _width;
/// Gets or sets the total width, in pixels, of this control.
@property int width() const {
    return _width;
}
/// ditto
@property void width(int value) {
    this._width = value;
}


Something like

/// Gets or sets the total width, in pixels, of this control.
@property const int width;

Is just so much nicer and saves so much bloat. I feel like the current property syntax is one of those places where IDE code snippets will start to become, not necessary, but extremely useful. It's the type of manual repetition that D aims to avoid, but in this case fails at.
I don't know if I agree with automatically expanding to const though. I'd like to be able to do '@property Control parent' without needing to return a const(Control) because the property is expanded to be const. Although if we had a virtual keyword, final is something that I think should be default for properties, and I think it's a mistake that the current @property doesn't infer final in the first place. Safe and nothrow are two assumptions that are probably quite safe to assume for the most part as well.

On Tuesday, July 02, 2013 19:49:39 Kapps wrote:
> On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:
> > I believe that the way that this sort of enhancement has
> > typically been
> > suggested is to do something like
> > 
> > public @property int value;
> > 
> > which would be lowered to something like
> > 
> > public @property int value() @safe const pure nothrow { return
> > _value; }
> > public @property int value(int v) @safe pure nothrow { return
> > _value = v; }
> > private int _value;
> > 
> > - Jonathan M Davis
> 
> As someone who uses properties almost everywhere, and almost never uses public fields, this is one of my biggest gripes with D remaining. It's incredibly annoying to have to do things like
> 
> private int _width;
> /// Gets or sets the total width, in pixels, of this control.
> @property int width() const {
> return _width;
> }
> /// ditto
> @property void width(int value) {
> this._width = value;
> }
> 
> 
> Something like
> 
> /// Gets or sets the total width, in pixels, of this control. @property const int width;
> 
> Is just so much nicer and saves so much bloat. I feel like the
> current property syntax is one of those places where IDE code
> snippets will start to become, not necessary, but extremely
> useful. It's the type of manual repetition that D aims to avoid,
> but in this case fails at.
> I don't know if I agree with automatically expanding to const
> though.

inout would probably be better then. But without that, anyone wanting to be const-correct is going to have to declare all of the getters themselves. inout isn't quite there, because there are many cases where you really do want to return const even when the object is mutable, but it would probably be a good compromise.

- Jonathan M Davis

"Kapps" <opantm2+spam@gmail.com> wrote in message news:zroaabiwkaxqybrtdhxp@forum.dlang.org...
>
> As someone who uses properties almost everywhere, and almost never uses public fields, this is one of my biggest gripes with D remaining. It's incredibly annoying to have to do things like
>
> private int _width;
> /// Gets or sets the total width, in pixels, of this control.
> @property int width() const {
>     return _width;
> }
> /// ditto
> @property void width(int value) {
>     this._width = value;
> }
>
>
> Something like
>
> /// Gets or sets the total width, in pixels, of this control. @property const int width;
>
> Is just so much nicer and saves so much bloat. I feel like the current
> property syntax is one of those places where IDE code snippets will start
> to become, not necessary, but extremely useful. It's the type of manual
> repetition that D aims to avoid, but in this case fails at.
> I don't know if I agree with automatically expanding to const though. I'd
> like to be able to do '@property Control parent' without needing to return
> a const(Control) because the property is expanded to be const. Although if
> we had a virtual keyword, final is something that I think should be
> default for properties, and I think it's a mistake that the current
> @property doesn't infer final in the first place. Safe and nothrow are two
> assumptions that are probably quite safe to assume for the most part as
> well.

You should probably try using template mixins, if all you need to do is expand some code.

On 2013-07-03 03:42, Daniel Murphy wrote:

> You should probably try using template mixins, if all you need to do is
> expand some code.

I don't think that works so well together with ddoc comments. Ideally you should be able to do something like this:

class Foo
{
    /// Get/set bar
    mixin property!(int, "bar");
}

-- 
/Jacob Carlborg

"Jacob Carlborg" <doob@me.com> wrote in message news:kr673g$179s$1@digitalmars.com...
> On 2013-07-03 03:42, Daniel Murphy wrote:
>
>> You should probably try using template mixins, if all you need to do is expand some code.
>
> I don't think that works so well together with ddoc comments. Ideally you should be able to do something like this:
>
> class Foo
> {
>     /// Get/set bar
>     mixin property!(int, "bar");
> }
>
> -- 
> /Jacob Carlborg

True, for now.

On 7/5/13, Jacob Carlborg <doob@me.com> wrote:
> I don't think that works so well together with ddoc comments. Ideally you should be able to do something like this:
>
> class Foo
> {
>      /// Get/set bar
>      mixin property!(int, "bar");
> }

Related: https://github.com/D-Programming-Language/dmd/pull/1485

Although this pull does the opposite of what's requested here.