"Properties" support in C++

[tgi...@gmail.com]

I know this has been discussed many times before with blocked results; but I truly feel if C++ is going to continue outstanding support and popularity into the future it needs to offer the basic idea of a "property".  There are many benefits to properties and the only arguments against them are ideological from a don't want to change point of view.

[Thiago Macieira]

I think you're generalising the problems and completely dismissing the valid
concerns raised. Your post above does not help improve the introduction of
properties into the language.

If you want to do that, write a proposal that provides the syntax and
mechanics of how properties would work. In that proposal, make sure you
address most of the concerns that people have raised.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[gmis...@gmail.com]

There's a lot and love and hate about properties. I think you're very wrong to write off the arguments against them so simply.

But since people do call for properties quite often, to entertain the idea for a bit, how about:

// Map assignment to any unknown member x into a function call to member set_x
// Map references to any unknown member x into a function named get_x

// Mapping could be done by default or opt/in out by prefix/pattern or individually.

// Example assume a default mapping.
class X
{

public:
    void set_x(int x);
    int get_x();
};

X x;
x.x = 100; // becomes x.set_x(100)
auto x = x.x; // becomes x = x.get_x();

// Allow explicit mapping

class X
{
public:
    void SetY(int x) get(y); // alias y
    int GetY() set(y); // alias y
};

x.y = 100; // becomes x.SetY(100)
auto y = x.y; // becomes x = x.GetY();

// Lots of potential issues to overcome, but that's the basic idea.

If this could work, perhaps existing code bases could be extended to support properties, some possibly fairly trivially.

[Cleiton Santoia]

I´m concerned about this for a while, and since someone touched the subject, let-me share few thoughts about what is wanted from properties:

1 - rule of "assignment" : given a object x from a class X that has a property p of type P, one should be able to attribute to x.p:

P z;
X x;
x.p = z;

2 - rule of "expression" : given a object x from a class X that has a property p of type P, one should be able to use x.p in any context where an expression of type Z is possible to appear:

P z;
X x;
z = x.p;

3 - rule of "underline value": given a object x from a class X that has a property p of type P, the value of p has outside of class X may be calculated at the time of use, and may or may not have a representation inside X;

4 - rule of "notification" : for every "assignment" or "use in an expression", a function (member or not) may be called to set or get the underline value of it.

5 - rule of "array" : given a object x from a class X that has an array property p of type P and a independent object q of type Q, one may write assignment and expressions using element q of x.p

P z1, z2;
X x;
Q q;
...
z1 = x.p[q];
x.p[q] = z2;

6 - rule of "default" : given a object x from a class X that has a (at most one) default property p of type P, one may omit it´s the name of the property p in it´s use ( this i think may be achieved using just cast operators )

P z;
X x;
Q q;
...
x.p = z; // is the same as
x = z;   // because p is a default property

and try not use any other keyword like @property or __property or prop. :)

 

If you want to do that, write a proposal that provides the syntax and
mechanics of how properties would work. 

 

With the help of community I might do that in a near future.

[tgi...@gmail.com]

Yes as many have posted while I've written this the general idea is well known.
If ( Object.Property == 34) { something } //Retrieve and compare value vs.
Object.Property = 34   //Set the attribute.

As for valid concerns I've have read; mostly composed of looped logic.

1) Knowing if something is being processed before setting the actual value.
OOP objects should work abstractly.  There shouldn't be direct access to internal variables and validation should occur when making "settings" to the object w/o having to validate outside the object.  If in the slightest bad case scenario one was to set a variable directly it should have syntax on the direct setting and not the interface (IE. Object.DirectVariable vs Object.Property).  I consider the first bad practice.  Think of this as a real physical object.  Does a car allow a rotation of 1200-degrees on the steering wheel?  It has limits applied directly on the wheel (human interface) itself.  From an abstraction level the idea that one can rotate a tire on the ground 1200-degrees doesn't seem like a legitimate concern for standard use interfaces.

2) Properties encourage a re-active scenario where an application re-acts to a property setting vs being told to re-act
This seems like looped logic.  Whether it be a property setting or a function call the application should re-act to changes.  That is what makes applications useful.  An application that "does" automatically what it needs to is what makes OOP applications powerful.

3) setters/getters does this.
Yes it does do the exact same thing except it doubles and clutters the API for no-known good reason.  Typical usage on set/get in C++ is Object.setField(3) and Object.getField().  Properties not only simplify this general case scenario (settings a single value to a single setting) but also from my perspective make single argument settings more readable as we know this same syntax is used on base data type settings.

Consider the following

using Person;
   Name = "John Doe"l
   Address = "Johns Road";

vs

using Person;
   setName("John Doe");
   setAddress("Johns Road");

I feel the gets/set syntax is over kill in single attribute/value settings and makes items less legible as well as clutters the API.  That's all there is to my proposal.

[Andrew Tomazos]

In C#, the core language feature called Properties works as follows:

class TimePeriod
{
    private double seconds;

    public double Hours
    {
        get { return seconds / 3600; }
        set { seconds = value * 3600; }
    }
}

We already have this in C++:

class TimePeriod

{

    double seconds;

public:

   struct {

       operator double() { return seconds / 3600; }

       void operator=(double value) { seconds = value * 3600; }

   } Hours;

};

In Java, Properties are a standard library feature which we can also replicate even easier.

So please give us an example of a language that offers "the basic idea of a "property"".  As far as I can see, properties are already a feature of C++.

On Thu, Jun 5, 2014 at 9:23 PM, <tgi...@gmail.com> wrote:

I know this has been discussed many times before with blocked results; but I truly feel if C++ is going to continue outstanding support and popularity into the future it needs to offer the basic idea of a "property".  There are many benefits to properties and the only arguments against them are ideological from a don't want to change point of view.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

[Miro Knejp]

Am 06.06.2014 06:07, schrieb Andrew Tomazos:
> We already have this in C++:
>
> class TimePeriod
> {
> double seconds;
>
> public:
>
> struct {
> operator double() { return seconds / 3600; }
> void operator=(double value) { seconds = value * 3600; }
> } Hours;
> };
>
>

This will not compile as the nested struct cannot access non-static
members of its enclosing type.

Miro

[Andrew Tomazos]

Yes, you're right of course.  You need to store the this pointer in the Hours object and make it a friend.  A little more boilerplate and maybe a little less efficient than what the compiler could do for you - but I still argue we basically have properties.

[Miro Knejp]

Am 06.06.2014 06:23, schrieb Andrew Tomazos:
> (...) A little more boilerplate and maybe a little less efficient than
> what the compiler could do for you (...)
>
To me this statement is an indication that maybe language support might
be worth considering, as a portable "zero cost" library solution is not
possible for something that could be done with no overhead by the
compiler. That being said I'm myself not sure whether properties in
general are a good idea as something that looks like an innocent member
access could be hiding an expensive operation without the user being
aware of its implication. The function call syntax at least makes the
reader aware that "something's possibly happening". And that being said
I can't remember how many times I wished I could give a member variable
public read access without having to boilerplate a getter every time.
I'm really not sure on which side of the fence I am here.

[Ville Voutilainen]

On 6 June 2014 07:23, Andrew Tomazos <andrew...@gmail.com> wrote:
>> This will not compile as the nested struct cannot access non-static
>> members of its enclosing type.
> Yes, you're right of course. You need to store the this pointer in the
> Hours object and make it a friend. A little more boilerplate and maybe a

You don't need to make it a friend, a nested class has access rights to the
members of the enclosing class.

[Andrew Tomazos]

Even better.

[Nicola Gigante]

Il giorno 06/giu/2014, alle ore 06:07, Andrew Tomazos <andrew...@gmail.com> ha scritto:

In C#, the core language feature called Properties works as follows:

class TimePeriod
{
    private double seconds;

    public double Hours
    {
        get { return seconds / 3600; }
        set { seconds = value * 3600; }
    }
}

We already have this in C++:

class TimePeriod

{

    double seconds;

public:

   struct {

       operator double() { return seconds / 3600; }

       void operator=(double value) { seconds = value * 3600; }

   } Hours;

};

The boilerplate of passing the this pointer is quite annoying (you have to do it in each constructor, for each property of the class), but to me is not the major drawback. The critical point here is memory: if you have 10 empty struct simulating 10 properties, you have 10 bytes = 1 byte for each struct, because of how empty members are handled. Of course this is even worse if the structs are not empty but each one contains a redundant this pointer. And no, the compiler is not allowed to optimize away this storage. To me that's not a solution good enough to say that C++ have properties. It doesn't. 

Then of course we could see _if_ we want them, which is not obvious (I'm myself skeptic about this proposal), but at least one have to start the discussion facing the truth.

My two cents. 

Greetings,

Nicola

[Ville Voutilainen]

On 6 June 2014 10:38, Nicola Gigante <nicola....@gmail.com> wrote:
> Then of course we could see _if_ we want them, which is not obvious (I'm
> myself skeptic about this proposal), but at least one have to start the
> discussion facing the truth.

I would like to more or less echo what Thiago said. If people wish to discuss
properties and come up with a new proposal for properties, they should first
do their homework and see why the earlier proposals were rejected, and
address those concerns. I would also like to point out that possible comments
like "I don't think that's a valid concern" are a waste of time. ;)

[David Krauss]

For what it’s worth, my upcoming inline variables proposal should help implement properties, although it may not be a complete solution. As of the last discussion on this list, it should eliminate the overhead of the proxy but not all the boilerplate, unless you forgo the setter. (With no setter, which may be quite reasonable, then an inline member variable should work perfectly.)

The main problem with properties is that a setter member access subexpression (e.g. x.prop in x.prop = 4) does not have a type. The RHS just magically plugs into the setter function parameter. Untyped subexpressions are a rough edge that the language tends to avoid. Even unqualified overloaded function names, including those of nonstatic member functions, have types, despite being unusable for anything besides a call. The way out is to introduce a proxy type, which is the ugly solution we already have.

[tgi...@gmail.com]

Lets just lay it out simple.  Almost every programming language under the sun short of C and C++ is supporting the idea of "properties".  If it's such a bad thing why is it so openly supported by most all other competing languages?  One just needs to google "How to make C# like properties in C++".  People are trying wacky ways to get this support by overloading the '=' operator and other listed here.

If the C++ ISO committee blocks this yet again; it's not a hit to anything but C++.  People have requested it; many want it.  It does not change any of the previous support/power of C++ so really not having original support is just telling the community who wants them that "we" have another reason to stop you from wanting to using C++.

[Ville Voutilainen]

On 6 June 2014 12:01, <tgi...@gmail.com> wrote:
> Lets just lay it out simple. Almost every programming language under the
> sun short of C and C++ is supporting the idea of "properties". If it's such

[citation needed]. I have no trouble finding very popular languages that don't.

> a bad thing why is it so openly supported by most all other competing
> languages? One just needs to google "How to make C# like properties in
> C++". People are trying wacky ways to get this support by overloading the
> '=' operator and other listed here.

Yes? People are trying wacky ways to support all sorts of features that
are available in other programming languages, and vice versa for c++
features.

> If the C++ ISO committee blocks this yet again; it's not a hit to anything
> but C++. People have requested it; many want it. It does not change any of

Apparently many enough don't, since it has been rejected.

> the previous support/power of C++ so really not having original support is
> just telling the community who wants them that "we" have another reason to
> stop you from wanting to using C++.

Well, if the lack of properties is preventing some people from using c++,
good riddance.

[Jean-Marc Bourguet]

Le vendredi 6 juin 2014 11:01:38 UTC+2, tgi...@gmail.com a écrit :

Lets just lay it out simple.  Almost every programming language under the sun short of C and C++ is supporting the idea of "properties".

If unbaked assumptions are allowed, I'll state that most languages don't have such a notion.

  If it's such a bad thing why is it so openly supported by most all other competing languages?  One just needs to google "How to make C# like properties in C++".  People are trying wacky ways to get this support by overloading the '=' operator and other listed here.

If the C++ ISO committee blocks this yet again; it's not a hit to anything but C++.  People have requested it; many want it.  It does not change any of the previous support/power of C++ so really not having original support is just telling the community who wants them that "we" have another reason to stop you from wanting to using C++.

There is currently nothing to block.  I'm not sure if there was ever something to block.  If I didn't mess up my look up, the latest related paper is one by David in 2004 which starts by "The purpose of this document is to inform WG21 (and the related national bodies) of the direction taken by the C++/CLI work in this area. This document is neither a proposal to include this extension in standard C++, nor an endorsement of this extension by the author."

Properties is something which come up informally quite often but nobody apparently want them enough to do the work of coming up with something more than raw ideas.

-- 

Jean-Marc

[Jean-Marc Bourguet]

Le vendredi 6 juin 2014 11:28:55 UTC+2, Ville Voutilainen a écrit :

Apparently many enough don't, since it has been rejected.

Did it go that far?  I found no paper in the last 10 years excepted N1600 which begins by "The purpose of this document is to inform WG21 (and the related national bodies) of the direction taken by the C++/CLI work in this area. This document is neither a proposal to include this extension in standard C++, nor an endorsement of this extension by the author."

Yours,

-- 

Jean-Marc

[Ville Voutilainen]

Try http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1384.pdf
and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf

[morw...@gmail.com]

There is also N1611: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf

It is not about "properties", but about "implicit functions". In short, function that could be called without operator(). The original purpose was to hide constants in functions, but it can also be used for properties.

[morw...@gmail.com]

There have also been some discussion on this very proposals forum:

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/HMyJqb3UIq0

There were some ideas to "extend functions syntax" instead of "adding properties", which is close to implicit functions. The advantage is that adding "implicit" to a function, would still allow to write it with the parenthesis. Therefore, we could "upgrade" some getters and setters to properties while the old code would still work.

On 28 August 2013 10:47, Bengt Gustafsson <bengt.gu...@beamways.com> wrote:

How about doing the change in the other end:

Don't change anything in the class head, but allow an implicit transformation:

object.property = value;

to

object.property(value);

IFF property is a function which has an overload that can be called with a single parameter of value's type.

As function pointers and functions are different I don't see that this can interfer with an assignment that is allowed today. Also this is consistent with what is already allowed at construction time!

The getter case is a little harder to accept for me, but I think it would be possible to allow:

int value = object.property;

IFF property is a method which has a 0-ary overload.

I am not positive but at least I think that using the address of a method without a leading & is not allowed when you really want to get at the method pointer, so this should not be ambiguous. In contrast, it would not be possible to omit the trailing () for a global function as (due to feature inheritance from C) this means the address of the function (correct me if I'm wrong on this).

One of the ideas I agreed with in this discussion was: "maybe we need properties, maybe we don't. But if we want them, let's not make them second-class members with a poor library solution, let's make them a proper part of the language". That's true: nobody would be happy with "half-properties" and nobody ever found any proper way to implement them without drawbacks as a simple library feature.

One of the core concern was to find a way to make the difference between the property getter/setter and the returned value. Consider an int property. Would sizeof(instance.some_property) return sizeof(int) ot sizeof(int (*)()) ? That's a real concern and could be problematic in generic code. In Python, type(instance.some_property) would be int, but Python's properties (the functions themselves) can still be accessed via reflection. Reflection may be a way to "solve" this problem.

Overall, I have grown to like properties, but there are still some rather serious core problems to resolve. What I said was pretty unstructured, but it sums up what was said in the old discussions.

[Diggory Blake]

Does C++ really need properties? It would make it very difficult to tell what's going on, and every instance of an implicit function call currently in the language has caused problems, such as implicit conversion operators, which make "auto" not quite do what you expect, break std::swap, complicate overload resolution, etc. Luckily these have been so far kept to a minimum, so I've always found it much easier to write less buggy code quickly in C++ than other languages, because it's very clear and precise - I can know that assigning to some field is not going to go and invoke some event handler which then breaks the invariants of my function, and so I don't have to go trawling through the (possible non-existent) documentation of whatever library I'm using to figure out whether my code might have unexpected side-effects.

I think the main problem is the tediousness of declaring the setters and getters, rather than any issue with having to use them (does anyone really care whether they have to use ".setXXX(y)" instead of "XXX = y", as long as they can get rid of all the boilerplate code used to declare those properties?) and that can be solved just be introducing a shorter syntax for declaring setters and getters with no side-effects.

[Thiago Macieira]

Em sex 06 jun 2014, às 02:01:37, tgi...@gmail.com escreveu:
> Lets just lay it out simple. Almost every programming language under the
> sun short of C and C++ is supporting the idea of "properties". If it's
> such a bad thing why is it so openly supported by most all other competing
> languages?

Most of those programming languages also got rid of pointers and use automatic
garbage collection. Are you also proposing we do the same for C++?

Just because other people do it does not imply we should do it.

That said, I'm going to stop this reply here and repeat what I said before:
write the paper proposing the feature. There's nothing to be discussed or
blocked until such a paper appears.

[Nicola Gigante]

What I don’t like about C#-like properties in C++, is the interaction with how
the language works in general.

For example, suppose “property” here is a property of type T:

auto x = obj.property;
should translate to auto x = obj.getProperty(), right?

But then you want this:
obj.property = 42;
to be translated to obj.setProperty(42);

So what should be the mechanism of this translation? In the first case the property is “used”,
so we call the getter, while in the second is “assigned”, so we call the setter?
But what if T provides operator=()? Should we “override” the operator=() with the setter?

But then if I do:

obj.property += 42;

what happens? Do we call the getter, since it’s not an assignment, and call operator+=() on the getter’s
result? It would be quite unexpected. Or do you want a different “setter” for each compound assignment
operator?

In C#, this mechanism works well because you can’t overload operator= on ref-types. It always assigns
references to objects. And compound assignment operators like += are always automatically implemented
based on binary operators like +. So the behavior of operations on a property is consistent with the behavior
of operations on a member field. In C++ it’s quite more difficult.

Also, we have references. obj.property can’t be an lvalue if the getter doesn’t return a reference, but
obj.property definitely looks like an lvalue. People are going to write:

void func(T &v)
{
v = 42;
}

func(obj.property);

It won’t compile. Or, worse, it would compile if the getter returns a reference, but doing something entirely different
from obj.property = 42; which IMHO is very bad. In C#, again, this problem doesn’t exist because we always have references
to objects.

And then if aren’t lucky you get this bonus misbehavior:

obj.property = 42; // call the setter
(obj.property) = 42; // call the getter and operator=()

It makes me screaming.

So no, I don’t think properties fit in C++.

My two cents,

Greetings,
Nicola

[Matthew Woehlke]

On 2014-06-06 01:02, Miro Knejp wrote:
> I can't remember how many times I wished I could give a member variable
> public read access without having to boilerplate a getter every time.

Amen to that.

Historically, I've actually done this:

public:
const T& x = mutable_x;
protected:
T mutable_x;

However this isn't necessarily the exact same thing as properties.

It might be nice to be able to write instead:

public:
using const x;
// or 'using const x = mutable_x'

protected:
T x;

--
Matthew

[Tom Joe]

Just wanted to add that MSVC has addressed these issues somehow with their compiler.  I'm not sure how they handle it since I'm actually rather a newbie to C++.

After reading N1384 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1384.pdf it appears this could be a user implemented design; but I feel most are going to want some standard langauge / library to make use of it.

__declspec( property( get=get_func_name ) ) declarator 
__declspec( property( put=put_func_name ) ) declarator 
__declspec( property( get=get_func_name, put=put_func_name ) ) declarator

--

---
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.

[Matthew Woehlke]

On 2014-06-06 09:10, morw...@gmail.com wrote:
> Would sizeof(instance.some_property) return sizeof(int) ot
> sizeof(int (*)()) ?

I'd have to lean strongly toward the former... in the case of implicit
functions, the above is "clearly" equivalent to:

sizeof(instance.some_getter())

...so the answer clearly is 'sizeof(int)'.

And anyway, you forgot a third option; 'sizeof(void (*)(int))'. Given
that ambiguity, I'd feel strongly that if you want the size of the
getter or setter, there would be some special syntax to indicate that
(and also if you want the get or the set).

--
Matthew

[Achille Roussel]

"properties" is a vague notion, I'm no sure it's really necessary to bring such concept to C++, here's what I've seen properties being used for:

1. auto-generating getters and setters

That would be something like declaring "property int n" and we'd get "void set_n(int)" and "int get_n() const" generated because the property is private. Honestly I don't really see how this could get interesting, if you're going to have a public getter and setter why not make your member public already? The syntax will be much easier to type and read with "x.n = 42" than "x.get_n()", and the compiler will generate a call to a generated "set_n" method. Saying that the underlying implementation of the class may change but not the public interface so we don't want to expose member variables is invalid in this case, since changing the class internals would require to re-compile the program and unless the variables type, names and layout didn't change that would break existing code.
The only place where I'd see this be useful would be if the setter and getters are virtual, because a sub-class implementation could be hidden and in that case it wouldn't break code using objects through the base type... I'm not sure that's a very relevant use case.

2. implicitly called functions

Some languages allow for nice looking syntax with implicit function calls (Python, Ruby... ), where functions that do little more than accessing a field of a sub object. You can write things like "x.n = 42" and that implicitly calls a method of the object, so we can do checks on the variable type for example... most languages I know that use this kind of approaches are dynamically typed and these kind of tricks allow for runtime type checking. But C++ already has a powerful type system so this isn't a use case.
Some other times, the implicitly called functions are used to check the runtime value of parameters or modify the values, for example, storing things internally with a different type than the one exposed in the public interface or making sure an integer stays within a certain range. These problems can easily be solved with library code and operator overloading, I don't think there's a need for a new language feature for this case.

3. Read-only or Write-only fields

So you make your class members public, but you want to make sure they are accessed in a read-only fashioned. First of all, if your objects are used through constant references this will be implicitly enforced, so the only case this is necessary would be when the object is available through a non-constant type.
You could make the fields constant but you can't assign instances of your class since it contains constant non-static members. So instead you could write some template "property" template class that wraps around the actual type and would provide read-only or write-only operations through operator overloading, until someone writes such a library to solve some real-world problems and shows which are the limitations enforced by the current C++ standard I don't think it's worth wasting time thinking about how to introduce a new syntax to support this use case.


Left aside issues like getting a pointer to member which happens to be a property... what would be the type of "&A::x" if x is a property of class A?
In the end I feel like there's very little interesting use-cases for properties in C++, and most of these problems could be solved with library code.

[Tom Joe]

I would say it is correct to say that it isn't necessary to bring the "properties" concept to C++; but there's a lot of nice things about C++ that aren't absolutely "necessary".

Agree; I also feel with a really good implementation that it could be introduced as a library, but also like to say properties it is an OO concept so I'm not sure that is a wise approach.

Just to summarize:

Pros:

1) read / write access definition

2) auto getters/setters routing

3) smaller API footprint     IMHO; this is the BIGGEST of all; whereas setThis(), getThis() does the same except it DOUBLES the object API.

4) More openly compatible with other OO languages and OO design concepts

Cons:

1) Hiding "notions" of a direct object variable access.

Am I missing any?

[dgutson .]

FWIW,

some (5?) years ago, I did a proof-of-concept of a library version
of properties, with 0 overhead.
The use case: https://code.google.com/p/mili/source/browse/examples/example_properties.cpp

The implementation:
https://code.google.com/p/mili/source/browse/mili/properties.h

I barely recall the details, but the main trick was to place all the
properties in a union at the beginning of the class, so "this" was
both the pointer of the property class and the container class.

I would probably implement it differently nowadays, too many things
changed, and I don't want to get into this discussion too deeply, just
to mention this idea.

Maybe a more general approach would be the ability to "embed" (or
enclose) classes into other classes, as a sibling flavor of
nesting-relationship, where "this" is shared. IOW, each embedded class
has access to the contained class' "this" ptr.

Hope this adds some value to the discussion.

Daniel.

On Thu, Jun 5, 2014 at 4:23 PM, <tgi...@gmail.com> wrote:
> I know this has been discussed many times before with blocked results; but I
> truly feel if C++ is going to continue outstanding support and popularity
> into the future it needs to offer the basic idea of a "property". There are
> many benefits to properties and the only arguments against them are
> ideological from a don't want to change point of view.
>

> --
>
> ---
> You received this message because you are subscribed to the Google Groups

> "ISO C++ Standard - Future Proposals" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--
Who’s got the sweetest disposition?
One guess, that’s who?
Who’d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

[Edward Catmur]

A convention used in quite a few places (Boost among others) is to write "properties" with a getter a nullary member function (usually const) and a setter a unary member function, both with the same name; foo(), foo(x), not getFoo(), setFoo(x).

This suggests a fairly conservative language extension to sugar property-style access to member functions following that convention:

1. Add to [lex.name] Table 3 an identifier with special meaning: property.  This can be written after nullary and unary member functions, and indicates that property-style access to that member function is enabled.

2. In the [expr.ref] rules for class member access where E1.E2 is a non-static member function, add the following:

If E2 is marked with property and the expression E1.E2 is the (possibly parenthesized) left-hand operand of an assignment expression, the assignment expression E1.E2 = E3 is rewritten to (E1.E2)(E3);

Otherwise, if E1.E2 is the (possibly parenthesized) left-hand operand of a member function call, then [the current rules apply];

Otherwise, if E2 is marked with property, the expression E1.E2 is rewritten to (E1.E2)();

Otherwise, the expression is ill-formed.

Here we're completely sidestepping the issue of the type and value category of a property access expression by presenting it as a syntactic rewrite. This means that we don't need to worry about pointers and references to member properties; other than their enhanced class member access rules properties are just member functions, and property doesn't affect their type at all.

Note that it is still possible to call the member function with usual (member function call) syntax. This is essential for being able to access overloads with higher arity. It also offers a pain-free adoption pathway for libraries that already use the suggested convention; just use a macro that expands to property on versions of C++ that offer the facility and expands to nothing on older versions.

Example:

struct S {
    int foo() const property;
    void foo(int i) property;
};
S s;
s.foo = 42;    // rewritten to s.foo(42);
std::cout << s.foo << '\n';    // rewritten to s.foo()

One remaining issue is compound assignment operators (and increment/decrement). I'm not sure whether to expand them or ban them entirely; one can see an argument for allowing employee.salary *= 1.05 e.g., expanding to employee.salary(employee.salary() * 1.05), but on the other hand for types with memory allocation such a rule could result in unexpected copies.

Regards, Ed

[Philipp Maximilian Stephani]

I link this idea, it requires only minimal modifications to the grammar.
One (mostly philosophical) objection would be that it overloads the meaning of the assignment operator.

Concerning compound assignment, I'd ban them for now. C++ doesn't require compound assignment to have the same meaning as binary operator + assignment, and a rewriting rule for properties would enforce such a rule and would make it harder to reason about what is actually happening.

A minor inconvenience is that, for mutable reference return types, the expression o.p++ would be invalid, but o.p()++ would be valid.

--

[Maurice Bos]

Maybe it'd be simpeler to not rewrite 's.foo = 42;' to 's.foo(42);',
but just to 's.foo() = 42;'. That way, there is nothing special about
the assignment operator, just that .foo is implicitly called. That
way, we can support-read only properties by just returning by value or
reference-to-const, read/write by returning a reference-to-non-const,
and support more advanced stuff (with value checking, etc.) by
returning an object of a type with (compound) assignment operator(s)
overloaded.

[Edward Catmur]

On Monday, 9 June 2014 11:11:16 UTC+1, Maurice Bos wrote:

Maybe it'd be simpeler to not rewrite 's.foo = 42;' to 's.foo(42);', 
but just to 's.foo() = 42;'. That way, there is nothing special about 
the assignment operator, just that .foo is implicitly called. That 
way, we can support-read only properties by just returning by value or 
reference-to-const, read/write by returning a reference-to-non-const, 
and support more advanced stuff (with value checking, etc.) by 
returning an object of a type with (compound) assignment operator(s) 
overloaded. 

That's what David Krauss's inline variables proposal would enable. I think it's elegant, but there's quite a bit of conceptual and syntactic overhead with the proxy object:

struct S {
    inline int foo() const { return ... }
    inline rw_property<int> foo() {
        return {
            [this]() { return ...; },    // getter
            [this](int i) { ... }    // setter
        };
    }
};

Note that you have to provide a separate const accessor, which increases the potential for code duplication and resultant errors.

[Philipp Maximilian Stephani]

However, the more advanced case with value checking will come up quite often because often it's the reason why properties are used in the first place instead of data members. I think this case should be kept as simple as possible, without requiring proxy objects.

> email to std-proposals+unsubscribe@isocpp.org.

> To post to this group, send email to std-pr...@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

[Cleiton Santoia]

What happens when you copy a class that has properties ?

[David Krauss]

Gutson’s system adds no state, so copyability isn’t harmed. Unions are copyable as long as all the members are trivially copyable, IIRC.

However, I think it’s a non-starter because it only works as long as this is equal to the address of the first member, which is only guaranteed for standard layout types. Adding a non-empty base or a virtual function kills it in practice.

It’s still very very clever though, and it definitely clears any lingering doubt that anything separates current C++ from properties besides the ability to get this from a nested class member function.

[Edward Catmur]

On Tuesday, 10 June 2014 23:10:53 UTC+1, David Krauss wrote:

Gutson’s system adds no state, so copyability isn’t harmed. Unions are copyable as long as all the members are trivially copyable, IIRC.

However, I think it’s a non-starter because it only works as long as this is equal to the address of the first member, which is only guaranteed for standard layout types. Adding a non-empty base or a virtual function kills it in practice.

Adding a known named member into the union allows locating it within the class:

struct property_tag {};
...
    union {
        property_tag properties;
...
    T& self() { return *(T*)((char*)(this) - ((char*)&(((T*)this)->properties) - (char*)this)); }

Example: http://coliru.stacked-crooked.com/a/9f95d3cf76fc8b97

 

It’s still very very clever though, and it definitely clears any lingering doubt that anything separates current C++ from properties besides the ability to get this from a nested class member function.

Perhaps what we need is a way to specify that an empty member shares the footprint of its class - something like EBCO for empty members?

[David Krauss]

On 2014–06–11, at 6:20 PM, Edward Catmur <e...@catmur.co.uk> wrote:

    T& self() { return *(T*)((char*)(this) - ((char*)&(((T*)this)->properties) - (char*)this)); }



Example: http://coliru.stacked-crooked.com/a/9f95d3cf76fc8b97

But, (((T*)this)->properties doesn’t really exist, so you get UB if its address happens to overflow the allocation block.

[Richard Smith]

You get UB regardless, for calling a member function on an object that doesn't exist. 

[Olaf van der Spek]

On Saturday, June 7, 2014 1:23:52 AM UTC+2, Achille Roussel wrote:

In the end I feel like there's very little interesting use-cases for properties in C++, and most of these problems could be solved with library code.

That's no argument for not standardizing such library code is it?

IMO public const access to fields would be very useful and trivial to implement.

Proper properties support is much harder to get right.

[Tom Joe]

Instead of the "what for" approach maybe a "why not" would make a more constructive argument.

Anyhow; I don't feel I have the severely needed C++ expertise to write and submit an informative and proper legitimate proposal short of stating it should mimic MSVC++ approach for compatibility.  If anyone feels up to it; jump in. :).

[max...@gmail.com]

I'm not convinced.  Properties can be extraordinarily expensive completely hidden calls.  This could be argued for any other kind of operator overloading, but in particular it is an affliction of getter properties which do a lot of processing in what looks like a no-op.

int x = test.size;

size could easily iterate over a million elements.  It looks like a simple assignment to an int.  There would be no indication you're actually doing a ton of work.

Here is a very real example of a problematic property I encountered in C# (using Unity) recently:

for( int i = 0; i < meshData.Vertices.Count; i++){

...

}

Over the course of iterating over the vertices about 8 megabytes of copying was occuring which in C# land means a lot of garbage.  Can you spot why?

meshData.Vertices returned a copy of the vertex array, and then .Count was called on that copy.  The allocations caused by looping in this manner created an extra ~2 second frame spikes while the garbage collector cleaned up on an iPhone.

Calling this, however, is basically free:

for( int i = 0; i < meshData.VertexCount; i++){

...

}

So, what was my take-away?  Properties are Evil(TM) they encourage unsafe and difficult to detect incorrect usage patterns.  If I were working in C++ I might have seen:

for( int i = 0; i < meshData.Vertices().Count; i++){

...

}

At this point the () triggers a very visual cue that something is up beyond simple member access.  Count appears to be cached, Vertices() is obviously a function call, and if I see that I can start to dig in.  Now, C++ doesn't have a garbage collector to worry about, and is way less liberal about unnecessary copies... But to say "there are many benefits to properties and the only arguments against them are ideological" is simply wrong.  Properties have absolutely been treated as second-class citizens in C#, and in Unity for sure, and they are a source of difficult to detect performance issues.

As an alternative idiom to properties I've adopted the following convenient syntax:

#include <iostream>

class MyClass {

public:

int x() const{

return m_x;

}

MyClass& x(int a_x){

m_x = a_x;

return *this;

}

int y() const{

return m_y;

}

MyClass& y(int a_y){

m_y = a_y;

return *this;

}

private:

int m_x = 0;

int m_y = 0;

};

int main(){

MyClass point;

point.x(5).y(10);

std::cout << point.x() << ", " << point.y() << std::endl;

}

[Thiago Macieira]

On Monday 07 July 2014 15:23:26 max...@gmail.com wrote:
> So, what was my take-away? Properties are Evil(TM) they encourage unsafe
> and difficult to detect incorrect usage patterns. If I were working in C++
> I might have seen:
>
> for( int i = 0; i < meshData.Vertices().Count; i++){
> ...
> }

It might have been:

for (int i = 0; i < meshData.Vertices->Count; ++i)

And you may not realise that Vertices is not a pointer, but an object that
overloaded operator->() and does expensive stuff there.

[Tom Joe]

I guess it depends on what language one has learned to begin with. 

As for myself; I have never assumed that within an OOP methodology that data access is direct.  Not that it couldn't be; but that it shouldn't be expected to be.  I've always thought of properties as being an abstraction-level part of OOP where data access within an object instance is correctly error validated and handled correctly by it's creator while treated externally the same as a variable/"property" access.

I do see very well Micheal's point though.  Even though the set/get doubles the API of everything; it also supplies at that API level more internal visibility (less abstraction) and by all accounts that can be taken as a very good benefit in many cases even if it does generally require a little more 'texty' code for the same task.

I think the most disturbing part of not having "properties" in C++ from someone who starts learning C++ is along the doubled API & texty points made above.  Which seems to beg the question; could there be a syntax that would flag visibly to the user the difference between a direct access variable and a re-directed one while still offering the syntactical sugar of general data access??  ( Object.DataSlot = 3.0; and If Object.DataSlot = 3.0 ).

I couldn't help but wonder if a "#" syntax could be used as Object.DataSlot# = 3.0 would be visible enough to think "That has property access routines" whereas Object.DataSlot = 3.0 "That's direct access".  To me that would be a beautiful feature even in languages like C#.  Although; I fear it would be a new language concept and would break and probably disturb a lot of MSVC programming code.

I guess when it all comes out in the wash; I'd like to think, "Making it available doesn't mean it has to be used." and I feel that making it available has enough benefits for the work involved for those who don't expect direct variable access in an OOP language.

--

---
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.

[Klaim - Joël Lamotte]

On Tue, Jul 8, 2014 at 12:23 AM, <max...@gmail.com> wrote:

size could easily iterate over a million elements.  It looks like a simple assignment to an int.  There would be no indication you're actually doing a ton of work.

It's true for almost any abstraction and this argument can be used against any improvements.

I don't consider this argument helpful to this discussion.

[Sean Middleditch]

There is a very real different between most C++ abstractions and their hidden costs and allowing properties. One example is operator->. A key bit here is that foo->bar and foo->baz will always have the same cost associated with operator->. You won't have foo->bar be cheap and foo->baz be heinously expensive. Going with the previous C# example, it's unlikely for Foo.Vertices.Count to be completely different than Foo.VertexCount from Foo's perspective in C++ since Foo.Whatever has a uniform behavior (access the member variable named Whatever in object Foo).

Yes, any abstraction can introduce hidden costs. Not all abstractions are equal, though. There's a lot of value in allowing overloads of + or * (for math types like complex, SIMD types, etc.) making the potential nonsense some users do a worthwhile risk. Likewise, some abstractions still provide clear points to watch out for, unless generic properties which allow two otherwise identical-looking constructs to have wildly different behaviors.

These two points combined, for me, damn properties. They don't actually make any difficult problems trivial and because they have low utility, their high cost is too much. From the context of C++, getters and setters work just fine. The point at which properties become important (even in C#) is during serialization and other metadata/introspection operations; that is, they're useful when interacting with external code or features and not the code itself. And then they're just an in-language syntax for grouping getters and setters in a way that easily exposes them to those introspection capabilities. However, there are other way of achieving that goal, ranging from more capable introspection that can group getters/setters, introspection with user-defined-attribute support that groups them, or markup facilities that construct a conceptual property that is used only by introspection and not C++ code itself (which is the status-quo for C++ metadata/introspection facilities today).

I would suggest that properties proponents come up with a solid set of use cases of things that you cannot do or cannot do easily in C++ today that properties would solve and try to very clearly illustrate their utility. As it stands today, I can't see any reason for properties besides "C# has them." C# has a lot of good ideas worth taking, a lot of bad ideas worth avoiding, and a lot of ideas that are just different ways of doing things and aren't worth the effort of "porting." Properties fall into the last category by every measure I can come up with personally, and almost certainly by every measure the committee and other knowledgeable C++ experts have. If you disagree, you're gonna have to prove us all wrong.

Short version: properties do not add significant value and can potentially do some harm so the benefit/cost ratio is just too low to make them worth adding to the language.

[Klaim - Joël Lamotte]

On Wed, Jul 9, 2014 at 1:18 AM, Sean Middleditch <sean.mid...@gmail.com> wrote:

On Tuesday, July 8, 2014 3:42:07 AM UTC-7, Klaim - Joël Lamotte wrote:

On Tue, Jul 8, 2014 at 12:23 AM, <max...@gmail.com> wrote:

size could easily iterate over a million elements.  It looks like a simple assignment to an int.  There would be no indication you're actually doing a ton of work.

It's true for almost any abstraction and this argument can be used against any improvements.

I don't consider this argument helpful to this discussion.

There is a very real different between most C++ abstractions and their hidden costs and allowing properties. One example is operator->. A key bit here is that foo->bar and foo->baz will always have the same cost associated with operator->. You won't have foo->bar be cheap and foo->baz be heinously expensive. Going with the previous C# example, it's unlikely for Foo.Vertices.Count to be completely different than Foo.VertexCount from Foo's perspective in C++ since Foo.Whatever has a uniform behavior (access the member variable named Whatever in object Foo).

Are you ignoring custom "smart" pointers here? Because as someone else pointed, you don't know the cost of calling ->. It totally depends on the implementation and it can change.

 

Yes, any abstraction can introduce hidden costs. Not all abstractions are equal, though. There's a lot of value in allowing overloads of + or * (for math types like complex, SIMD types, etc.) making the potential nonsense some users do a worthwhile risk. Likewise, some abstractions still provide clear points to watch out for, unless generic properties which allow two otherwise identical-looking constructs to have wildly different behaviors.

To clarify, I'm not against properties, I think it can help in a lot of situations. However I think that focusing on the cost of an arbitrary implementation of a useful abstraction is not helpful to the discussion.

Basically, it's like saying that properties (whatever the form it takes) seems useful for stabilizing interfaces with accessors, but can also be used to do some dumb stuffs, as any powerful abstraction tool.

 

These two points combined, for me, damn properties. They don't actually make any difficult problems trivial and because they have low utility, their high cost is too much. From the context of C++, getters and setters work just fine. The point at which properties become important (even in C#) is during serialization and other metadata/introspection operations; that is, they're useful when interacting with external code or features and not the code itself. And then they're just an in-language syntax for grouping getters and setters in a way that easily exposes them to those introspection capabilities. However, there are other way of achieving that goal, ranging from more capable introspection that can group getters/setters, introspection with user-defined-attribute support that groups them, or markup facilities that construct a conceptual property that is used only by introspection and not C++ code itself (which is the status-quo for C++ metadata/introspection facilities today).

I think that introspection don't solve the main problem that properties solve: being able to switch from a public member (from a raw struct) to an accessor function, without breaking user's code.

Maybe gathering data on properties use through time would be better than discussing unknown performance implication, and making the discussion going full circle.

Anyway I don't think I've seen any properties proposal being published in the end. Such proposal should, in my opinion, point to some data.

 

I would suggest that properties proponents come up with a solid set of use cases of things that you cannot do or cannot do easily in C++ today that properties would solve and try to very clearly illustrate their utility. As it stands today, I can't see any reason for properties besides "C# has them." C# has a lot of good ideas worth taking, a lot of bad ideas worth avoiding, and a lot of ideas that are just different ways of doing things and aren't worth the effort of "porting." Properties fall into the last category by every measure I can come up with personally, and almost certainly by every measure the committee and other knowledgeable C++ experts have. If you disagree, you're gonna have to prove us all wrong.

 

Short version: properties do not add significant value and can potentially do some harm so the benefit/cost ratio is just too low to make them worth adding to the language.

I don't totally agree with the conclusion because I've seen some use cases (evolution from public member to accessor function) 

but I don't have a strong opinion on including properties as one solution to avoid this case is to never expose public member.

I think a properties system that enforce that the returned object is a member of the type would be a good start, instead of allowing anything to be generated as output of the property.

That way:

 1. properties address would be valid;

 2. properties providing a temporary would be forbidden;

 3. checks and other side-effects on accessing a member would still be possible;

 4. from this restricted version, evolution would still be possible;

And as you say, such a proposal should provide use cases.

 

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

[Sean Middleditch]

On Tuesday, July 8, 2014 4:35:29 PM UTC-7, Klaim - Joël Lamotte wrote:

There is a very real different between most C++ abstractions and their hidden costs and allowing properties. One example is operator->. A key bit here is that foo->bar and foo->baz will always have the same cost associated with operator->. You won't have foo->bar be cheap and foo->baz be heinously expensive. Going with the previous C# example, it's unlikely for Foo.Vertices.Count to be completely different than Foo.VertexCount from Foo's perspective in C++ since Foo.Whatever has a uniform behavior (access the member variable named Whatever in object Foo).

Are you ignoring custom "smart" pointers here? Because as someone else pointed, you don't know the cost of calling ->. It totally depends on the implementation and it can change.

I don't think you're seeing what I said. Say foo is a smart pointer. What is the smart pointer's cost for the following?

  foo->bar.gar

vs.

  foo->baz.gar

 

The answer is that the cost is identical, as both are calling the exact same decltype(foo)::operator->, and then invoking the built-in -> and . operators to access member variables.

With properties, however, what is the cost difference between these?

   foo.bar.gar

vs

   foo.baz.gar

The answer is "you have no idea" because either could be calling two different hidden getters.

This is a subtle difference, but it's a difference.

 

Yes, any abstraction can introduce hidden costs. Not all abstractions are equal, though. There's a lot of value in allowing overloads of + or * (for math types like complex, SIMD types, etc.) making the potential nonsense some users do a worthwhile risk. Likewise, some abstractions still provide clear points to watch out for, unless generic properties which allow two otherwise identical-looking constructs to have wildly different behaviors.

To clarify, I'm not against properties, I think it can help in a lot of situations. However I think that focusing on the cost of an arbitrary implementation of a useful abstraction is not helpful to the discussion.

Basically, it's like saying that properties (whatever the form it takes) seems useful for stabilizing interfaces with accessors, but can also be used to do some dumb stuffs, as any powerful abstraction tool.

And to clarify, I am very much against properties.

 

These two points combined, for me, damn properties. They don't actually make any difficult problems trivial and because they have low utility, their high cost is too much. From the context of C++, getters and setters work just fine. The point at which properties become important (even in C#) is during serialization and other metadata/introspection operations; that is, they're useful when interacting with external code or features and not the code itself. And then they're just an in-language syntax for grouping getters and setters in a way that easily exposes them to those introspection capabilities. However, there are other way of achieving that goal, ranging from more capable introspection that can group getters/setters, introspection with user-defined-attribute support that groups them, or markup facilities that construct a conceptual property that is used only by introspection and not C++ code itself (which is the status-quo for C++ metadata/introspection facilities today).

I think that introspection don't solve the main problem that properties solve: being able to switch from a public member (from a raw struct) to an accessor function, without breaking user's code.

Depending on user's code, that change violates all kinds of API contracts like "this is just a memory dereference" or "it's just a member I can access via a pointer-to-member" which is actually important in all kinds of use cases and performance-sensitive industries like embedded, HPC, and games. It also still breaks ABIs for users of shared libraries exposing the change, too. It introduces a lot of pitfalls for what I still assert is very little actual benefit.

If you're changing from a simple struct (implying a small, simple semantically-"tagged" collection of data) to something with logic and run-time overhead in member gets or sets then you are fundamentally changing the type and its characteristics. Trying to pretend that you are not fundamentally changing it is far more damaging to code maintainability than users needing to update their API usage occasionally, IMO.

[Tom Joe]

I would suggest that properties proponents come up with a solid set of use cases of things that you cannot do or cannot do easily in C++ today that properties would solve and try to very clearly illustrate their utility

- Actually I think you already answered the same question  you requested.

The point at which properties become important (even in C#) is during serialization and other metadata/introspection operations; that is, they're useful when interacting with external code or features and not the code itself. And then they're just an in-language syntax for grouping getters and setters in a way that easily exposes them to those introspection capabilities. However, there are other way of achieving that goal, ranging from more capable introspection that can group getters/setters, introspection with user-defined-attribute support that groups them, or markup facilities that construct a conceptual property that is used only by introspection and not C++ code itself (which is the status-quo for C++ metadata/introspection facilities today).

- Certainly you can hobnob all the above using some other lengthy home-baked process; but the real question is why would you want to?

Likewise, some abstractions still provide clear points to watch out for, unless generic properties which allow two otherwise identical-looking constructs to have wildly different behaviors.

- I gather this is the "real" debate here.  Programmers who have become use to associating object data with direct access variables.  It's a valid point to be considered but it's also a valid point that properties general cut the user-API of a class in half (due to not requiring a set/get for every data member that isn't direct access). 

As mentioned before it makes the class interface more abstract to the user while also simplifying it for general usage.  For example what is the real difference between "Object.SetData(3);, Object.GetData()" and Object.Data.  Currently; two can have code and one never does however there's 2-Public Class function calls vs only one with properties.  But with that "one" we loose the ability to know if it's direct-access or if something else is happening but we also gain the ability to do both or all three(coded direct) with one caller an the class create gets to determine that.  Either one is comfortable with that or they are not.  By all means it is an abstraction level that "looks" like and somewhat operates like a variable. 

I can relate to the concerns as I can't count the number of times I've seen programmers dump a bunch of un-necessary functionality code into a get-property and thought to myself why would they do that there knowing the outside world may be calling that multiple times - at the very least put a 'DoOnce' wrapper around it if the value is still the same; but as much as could be said about any other part of programming.  This is where OOP methodology learning I think causes the debate.  I think for some of us the OOP idea of direct-data-access is a bad-practice.  With this other OOP methodology the idea is the class variables are all private and any access to it's "internal" data is held hostage by the class creator who allows special public access to the data but only under the class creators "OK" and verification that what needs to be taken into consideration on a data change is taken into consideration.  With that as a best practice the direct-access isn't an option and property abstraction is inevitable.

--

---
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.

[Tom Joe]

Just another summary; Since I feel I keep repeating the same things over and over again.

The root decision that needs to be made;

1) Should a C++ programmer be "allowed" (Allowed being the keyword) to use an ISO "standard" property abstraction.

    In Favor say;      Smaller API - that replaces the need for both a set/get function in order to wrap for abstraction easily in a widely accepted standard.

    Against say;      Limits visibility; user difference between direct access and abstracted access is not readily demanded/determined by syntax.

Frankly; Why couldn't their be a syntax that had both benefits of a property but the clarity of abstraction?  Even a 'best notation practice' could be used like, "Any direct access member should be ended with an  '_'".  Not that it's a good idea to use '_'; but point being why can't both sides have a favorable/acceptable return?  If C++ standard should enforce a syntax making surface-visible direct-access notification possible; I'm actually very much in favor of it.  But to just block a property usage standard all-together I find ... well "blocking" progress minded.

[J. Daniel Garcia]

> Lets just lay it out simple.  Almost every programming language under the
> sun short of C and C++ is supporting the idea of "properties".  If it's such

[citation needed]. I have no trouble finding very popular languages that don't.

In particular: I would be quite interested in "every programming language" goitng through a standardization process.

 

> a bad thing why is it so openly supported by most all other competing
> languages?  One just needs to google "How to make C# like properties in
> C++".  People are trying wacky ways to get this support by overloading the
> '=' operator and other listed here.

Yes? People are trying wacky ways to support all sorts of features that
are available in other programming languages, and vice versa for c++
features.

> If the C++ ISO committee blocks this yet again; it's not a hit to anything
> but C++.  People have requested it; many want it.  It does not change any of

Apparently many enough don't, since it has been rejected.

> the previous support/power of C++ so really not having original support is
> just telling the community who wants them that "we" have another reason to
> stop you from wanting to using C++.

Well, if the lack of properties is preventing some people from using c++,
good riddance.

--

---

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

[Olaf van der Spek]

On Wed, Jul 9, 2014 at 2:25 AM, Sean Middleditch
<sean.mid...@gmail.com> wrote:
> I don't think you're seeing what I said. Say foo is a smart pointer. What is
> the smart pointer's cost for the following?

I think he does, but you don't get what he's saying. ;)
Suppose we've got a->b vs c->b with a and c being two different types
of pointers. What's the cost of doing -> ?
They're two different hidden functions...

> With properties, however, what is the cost difference between these?

> The answer is "you have no idea" because either could be calling two
> different hidden getters.
>
> This is a subtle difference, but it's a difference.

Hidden function calls are everywhere in C++, if you don't want such
hidden calls C might be a better language for you.

> Depending on user's code, that change violates all kinds of API contracts
> like "this is just a memory dereference" or "it's just a member I can access
> via a pointer-to-member" which is actually important in all kinds of use
> cases and performance-sensitive industries like embedded, HPC, and games. It
> also still breaks ABIs for users of shared libraries exposing the change,
> too. It introduces a lot of pitfalls for what I still assert is very little
> actual benefit.

I'm not sure that's entirely right. Moving from a simple property
(with trivial get/set) to one with a user-defined get/set doesn't have
to change the ABI.
Sure, performance etc are important but that's no argument to deny all
users a feature is it?



--
Olaf

[Nevin Liber]

On 9 July 2014 03:08, Olaf van der Spek <olafv...@gmail.com> wrote:

Sure, performance etc are important but that's no argument to deny all
users a feature is it?

That argument cuts both ways.  After all, one of the rationales presented in this very thread is:

On 6 June 2014 00:02, Miro Knejp <mi...@knejp.de> wrote:

Am 06.06.2014 06:23, schrieb Andrew Tomazos:

(...) A little more boilerplate and maybe a little less efficient than what the compiler could do for you (...)

To me this statement is an indication that maybe language support might be worth considering, as a portable "zero cost" library solution is not possible for something that could be done with no overhead by the compiler. 

 So, should we be considering performance or not?

--
 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404

[David Krauss]

On 2014–07–09, at 10:35 PM, Nevin Liber <ne...@eviloverlord.com> wrote:

> So, should we be considering performance or not?

That ship sailed with implicit conversions.

Implicit conversions can be used to implement properties. A properties extension wouldn’t add any fundamentally new capabilities. It would only provide something convenient and efficient enough to be less frowned upon.

IMHO, we’re arguing over micro-optimization of programs written by boilerplate-happy, ignorant, and superstitious users. Their programs will tend to be slow because they do various other unnecessary things besides getter functions, but not careful selection of algorithms.

Fact is, most programs are going to run fast enough no matter what you do, because computers are fast. Slowness due to complex getters is as fixable as any other performance issue.

You just have to trust folks to write whatever they want to write. Occasionally a raw, exposed member should be refactored with a getter. Although it’s far less common than OO zealots would have you believe, there’s no reason the language should make it so difficult.

[masse....@gmail.com]

On Wednesday, July 9, 2014 1:35:29 AM UTC+2, Klaim - Joël Lamotte wrote:

I think that introspection don't solve the main problem that properties solve: being able to switch from a public member (from a raw struct) to an accessor function, without breaking user's code.

I do no think properties does solve this problem either. Even in C#, if you change a class member into a property, then the user code gets broken and a recompilation of the dependend code is required to make things works again.
The difference I see here is that you don't need to change the code. You just need to recompile. (Is that what you meant?)

[Nevin Liber]

On 9 July 2014 10:03, David Krauss <pot...@gmail.com> wrote:

Fact is, most programs are going to run fast enough no matter what you do, because computers are fast.

Fact?

Maybe that is true in your particular domain, but for those of us who have to deal with latency, throughput, power consumption, etc., performance is definitely important.

[Klaim - Joël Lamotte]

Yes, recompiling is fine, like for any change in a header anyway. (I'm ignoring ABI issues for the moment).

[Klaim - Joël Lamotte]

On Wed, Jul 9, 2014 at 5:03 PM, David Krauss <pot...@gmail.com> wrote:

Fact is, most programs are going to run fast enough no matter what you do, because computers are fast.

Not if the target platform is slow whatever you wish from it. Not all computers are fast. 

I'm thinking about several cases in my experience where it's totally wrong to think that way, like most embedded software excluding smartphones.

[Nevin Liber]

On 6 June 2014 08:10, <morw...@gmail.com> wrote:

One of the ideas I agreed with in this discussion was: "maybe we need properties, maybe we don't. But if we want them, let's not make them second-class members with a poor library solution, let's make them a proper part of the language". That's true: nobody would be happy with "half-properties" and nobody ever found any proper way to implement them without drawbacks as a simple library feature.

That may be, but another feature, lambdas, got its start as a library (Boost.Lambda is one example) and it showed the drawbacks of a library based solution.  (Note:  some of this is speculation on my part, as I was not on the Committee when lambdas were deliberated.)  Yet it was widely adopted and people used it, despite the pain.

Why isn't there a widely adopted properties library?

[Michael Hamilton]

"Why isn't there a widely adopted properties library?"

I completely agree with Nevin.

I believe making a "boost properties" module would be a good first step to a serious proposal.  I am not in favor of properties, but that's personal taste.  Let adoption dictate the desire. 

Honestly though, the issue with adding any feature to the language is that you cannot suggest: "don't use it if you don't want it."

My issue with properties came directly from a third party library doing something unexpected.  Unity does other helpful things like:

myMesh.sharedMesh vs myMesh.mesh one of these deep copies, the other returns a shared reference.

I don't get to opt-in or opt-out of this in a work environment, it is just one more thing I need to know.  Adding this to C++ would have a similar impact on everyone as they begin to propogate.

It would be like arguing "well, const correctness is completely optional" (I love const correctness, don't get me wrong, but it is a similar thing in how it propagates through code-bases.)  It's also like saying "shared_ptr is just another feature you can choose to use or not."  But in reality a lot of libraries return+require shared_ptr handles to things which forces system-wide adoption (for those types at least).

When you add something new to a language, everyone ends up eating it one way or another.

--

---
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.

[Michael Hamilton]

I'd like to add one more thought to my previous post.

Properties make interfaces easy to use incorrectly.  I believe implicit casting is similar in this regard (and widely it is frowned upon.  The fact that properties can be implemented in C++ with implicit casting is actually pretty telling.)

I feel like this is a very C# way of doing things.  C# enjoys making users of libraries leak non-memory resources unless they *know* the library writer intended them to wrap something in a "using" block, for example.  This is the kind of thing C libraries do with begin/end pairs being required, but modern C++ has moved away from with more idiomatic use of RAII.

Just a thought on differing language philosophies.

[Ville Voutilainen]

On 9 July 2014 21:56, Michael Hamilton <mi...@m2tm.net> wrote:
> "Why isn't there a widely adopted properties library?"
>
> I completely agree with Nevin.
>
> I believe making a "boost properties" module would be a good first step to a
> serious proposal. I am not in favor of properties, but that's personal
> taste. Let adoption dictate the desire.

Funny, this reminds me of
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/HMyJqb3UIq0/tWAwN20E1hQJ

It still seems to me that properties don't quite cross the bar of a
language feature; all discussions
seem to boil down to being able to refactor direct member accesses to
actually be function
calls without modifying the clients, and then there's a discussion
meltdown on what "the right"
thing for properties supposedly is. The resulting lack of
agreement/consensus then kills
the idea. Personally, yes, I suppose it would be nice to be able to
refactor member access into
a function call, but I would _never_ leave it at that. At some point I
would change those
member accesses to actually _look_ like function calls, since that's
what they are. I do
think it would be somewhat funny, philosophically, to let people
refactor design mistakes
by "papering over" them, with a language feature.

[David Krauss]

On 9 July 2014 10:03, David Krauss <pot...@gmail.com> wrote:

Fact is, most programs are going to run fast enough no matter what you do, because computers are fast.

On 2014–07–10, at 12:03 AM, Nevin Liber <ne...@eviloverlord.com> wrote:

Fact?

Maybe that is true in your particular domain, but for those of us who have to deal with latency, throughput, power consumption, etc., performance is definitely important.

On 2014–07–10, at 12:41 AM, Klaim - Joël Lamotte <mjk...@gmail.com> wrote:

Not if the target platform is slow whatever you wish from it. Not all computers are fast. 

I'm thinking about several cases in my experience where it's totally wrong to think that way, like most embedded software excluding smartphones.

Programmers who program actually-slow computers are a different breed. The programs run by such computers fall outside the “most programs” of my claim.

Implicitly-called functions with significant complexity, be they accessors or implicit conversions, are a stupid thing to write and a good way to get fired. Programs will not get slower because the language has such a facility. It will not be tempting to embedded programmers, who should live by the rule: You don’t pay for what you don’t use.

There is a subculture of OO superstition propagated by awful Java teachers. It is probably the worst thing ever to befall software engineering. However, its disciples will just invariably write accessor functions anyway, “just in case” the complexity needs to be added later. Native properties support would just give them a cushion, so their code could look more reasonable.

People will tend to express whatever they like in a given language. Censorship by grammar doesn’t work.

[David Krauss]

On 2014–07–10, at 7:39 AM, David Krauss <pot...@gmail.com> wrote:

> People will tend to express whatever they like in a given language. Censorship by grammar doesn’t work.

Put another way: properties extend the expressive power of a language by allowing segregation of fast accessors (according to program architecture, “fast” may vary from a few instructions to O(lg N) ) from potentially slow ones. Without properties, everything looks potentially slow. What’s the benefit in that?

To be sure, in reality everything truly is potentially slow. A simple member access may cause a page fault. Only a profiler will really tell; the language can only express intent.

[Adam Nevraumont]

Is there a way we can do this as a library solution?

In C++1y, uncompiled:

   // is_invokable:
   template<class> using sink_t=void;
   template<typename Sig, typename=void>
   sturct is_invokable:std::false_type{};
   template<typename R, typename... Args>
   struct is_invokable< R(Args...), sink_t< std::result_of_t< R(Args...) > > >:std::true_type{};
   template<typename Sig>using is_invokable_t=typename is_invokable<Sig>::type;

   // get/set object with cast and assign overriden:
   template<typename Get, typename Set>
   struct property_t {
     Set set; Get get;
     template<typename T, typename=std::enable_if_t< std::is_convertible< std::result_of_t< Get() >, T >::value >>
     operator T() && { return get(); }
     template<typename T, typename=is_invokable_t<Set(T)>> // is_invokable_t left as exercise
     property_t operator=( T&& t ) && {
       set(std::forward<T>(t));
       return std::move(*this);
     }
    };

   // helper to let you pass lambdas in:
   template<typename Get, typename Set>
   property_t<Get,Set> property( Get&& get, Set&& set ) { return { std::forward<Get>(get), std::forward<Set>(set); }; }

   // sample use:
   struct Square {
      double width;
      auto area() const { return property(
          [=]() {return width*width;},
          [=](double area) {width = sqrt(area);}
        );
     }
   };

  int main
At point of use, this can act nearly identical to C# style properties, except the user has to add ().

Syntax wise, it isn't much heavier than the get() set() syntax of C# style properties.  It is a bit ... generous ... with the types it will cast to.

Am I missing something?

- Adam

[Nevin Liber]

On 10 July 2014 13:32, Adam Nevraumont <a...@theorem.ca> wrote:

Is there a way we can do this as a library solution?

My question still stands:

Why isn't there a widely adopted properties library?

Now, if you design a properties library AND it becomes widely adopted, IMO it would then be appropriate to revisit the question of standardizing it (either as a library or a language feature).

Until then, such a proposal is unlikely to go anywhere.  IMHO, of course.

[Tom Joe]

My question still stands:

Why isn't there a widely adopted properties library?

I would imagine some of the answer to that would probably have to do with there not having a standard one for anyone to refer too yet.  It seems to be typically half-baked-implemented by code and called "good-enough".

However, If one googles it there does exist many non-standardized and fluctuating implementations of properties as well as a plethora of code implementations samples (Even on Wikipedia).

http://en.wikipedia.org/wiki/Property_%28programming%29
http://www.cplusplus.com/forum/general/8147/
http://how-bazaar.blogspot.com/2011/07/properties-in-c.html
http://www.codeproject.com/Articles/3900/Implementing-Properties-In-C
http://psl.sourceforge.net/
http://www.boost.org/doc/libs/1_44_0/boost/test/utils/class_properties.hpp

--

[David Krauss]

On 2014–07–11, at 2:32 AM, Adam Nevraumont <a...@theorem.ca> wrote:

> Is there a way we can do this as a library solution?
>

> Am I missing something?

You got it!

There are a few potential rough edges in that implementation, but perhaps that’s an argument in favor of adding a vetted, safe library to the standard.

Effectively, the only thing stopping everyone from using properties in the past was the difficulty of writing a metaprogram as you just did. If improvements to ease of metaprogramming have brought this within reach to more users, then the Standard should get off its high horse and respond to demand.

[Ville Voutilainen]

On 11 July 2014 01:10, David Krauss <pot...@gmail.com> wrote:
> Effectively, the only thing stopping everyone from using properties in the past was the difficulty of writing a metaprogram as you just did. If improvements to ease of metaprogramming have brought this within reach to more users, then the Standard should get off its high horse and respond to demand.

I'm sure it will, if there ever is such demand in sufficient quantities.

[Tom Joe]

With the number of property proposals in this very forum as well as the countless adhoc implementations posted in various places around the net and the multiple dis-appointed user comments one gets when googling "properties in C++" I'm rather curious as to what number would qualify as "sufficient quantities"? 

I think the demand is there and that one of ISO C++'s larger "sore-thumb's" is the lack of such support.  It appears, to me, accurate to say that ISO C++ is one of the very few largely accepted languages missing support (Which isn't even true of MSVC or C++/CLI but specifically to GCC ISO collection).  Even the Qt library developers speak of how they had to "work around" not having native C++ property support.  Whether support is a blessing or a curse appears to be up in the air; but I do believe the demand is well established and visible.

[Ville Voutilainen]

On 11 July 2014 10:20, Tom Joe <tgi...@gmail.com> wrote:
> With the number of property proposals in this very forum as well as the
> countless adhoc implementations posted in various places around the net and
> the multiple dis-appointed user comments one gets when googling "properties
> in C++" I'm rather curious as to what number would qualify as "sufficient
> quantities"?

A majority number of WG21 members voting in an actual proposal for properties.

[Tom Joe]

Awe yes; very good point.  I was actually under the assumption that this forum was monitored/read by WG21 members;  If so, I'd like to propose a vote at the next meeting.  Guess I had assumed that's what this forum was for.

[Ville Voutilainen]

On 11 July 2014 10:34, Tom Joe <tgi...@gmail.com> wrote:
> Awe yes; very good point. I was actually under the assumption that this
> forum was monitored/read by WG21 members; If so, I'd like to propose a vote

It is; I, for example, am a WG21 member.

> at the next meeting. Guess I had assumed that's what this forum was for.

You need a proposal (an actual paper) to get a motion to vote on. That proposal,
if it is a language extension, needs to be accepted by both EWG (for the design)
and CWG (for the wording) (or LEWG and LWG, for a library addition)
before it'll have a chance to get voted on by the full committee.

[Tom Joe]

Excellent; Guess my assumptions were pretty close.  As stated previously I'm really not a seasonal-ed C++ programmer with the equipment necessary to write a decent proposal so if anyone wants to jump in and take these discussions to the next level I'd be more than happy to be of any but likely no-assistance help at all :)..

That said as a seasoned programming across multiple languages; I think Michaels and Seans arguments are substantial and I can see a huge benefit of having syntactical flaggers between the differences of a property and field (direct-access).  It may break all previous standards in other languages but it may be the tipping innovation that makes properties happier for all programmers to use.  Be it Object.Property# or Object-|Property vs Object->Field.  Thoughts?

[Bo Persson]

Tom Joe skrev 2014-07-11 10:47:
> Excellent; Guess my assumptions were pretty close. As stated previously
> I'm really not a seasonal-ed C++ programmer with the equipment necessary
> to write a decent proposal so if anyone wants to jump in and take these
> discussions to the next level I'd be more than happy to be of any but
> likely no-assistance help at all :)..
>
> That said as a seasoned programming across multiple languages; I think
> Michaels and Seans arguments are substantial and I can see a huge
> benefit of having syntactical flaggers between the differences of a
> property and field (direct-access). It may break all previous standards
> in other languages but it may be the tipping innovation that makes
> properties happier for all programmers to use. Be it Object.Property#
> or Object-|Property vs Object->Field. Thoughts?
>

Being able to use Object.Property# instead of Object.Accessor() doesn't
seem like an improvement to me.


Bo Persson

[Michael Hamilton]

I feel like postfixing isn't really what you want here (it's too similar to a function syntax anyway):

something = object~property;

something = objectPtr~>property;

object~property = something;

objectPtr~>property = something;

Something like that would be fine with me.  A visual indication in a similar way to function call vs member call is in order certainly.  This also keeps the same number of characters as regular . or -> syntax so the purpose of the property (convenience) is maintained.

My primary complaint about properties is their invisible nature at the call site, this would erase that concern.

In terms of declaration syntax I don't care so much *shrug*:

class MyClass{

public:

     int bar~ {

          get: {return bar * 2;}

          set: {bar = value / 2;}

     }

private:

     int bar;

};

--

--- You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.

To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscribe@isocpp.org.

[Michael Hamilton]

class MyClass{

public:

     int bar~ {

          const get: {return bar * 2;}

          set: {bar = value / 2;}

     }

private:

     int bar;

};

[Tom Joe]

I feel like post-fixing isn't really what you want here (it's too similar to a function syntax anyway):

something = object~property;

something = objectPtr~>property;

---

Visually; I prefer the operator identifier also.  But one concern I had with this route was how IDE tools with intellisense would differentiate the "." from the "~" list.  If only properties are shown with a "~" is that going to hide important API discovery?  If both are shown but only properties can be used is that going to be upsetting in natural usage?  Also wondered if the implementation would be stickier.  Seems minor but something to consider.

Post-fixing certainly looks more like a hack job but carries the same syntax identifier location as functions ( # for properties; () for functions ); which I'd actually relate to a positive instead of a negative.  Wonder if the rule, "Any identifier with a '#' post-fix is identified by C++ as a property" would be a solution.  I also was thinking the 3.0 CLI syntax may be a nice advantage.

object.property# = 0;

object.field = 3;

If (object.property#) then object.property# = object.property# + 1

class MyClass{

public:

    // CLI 3.0 syntax - compiler auto creates standard assignment vs written out ones - just like a field but has access-or wrappers for those who believe this is good practice to kill off a little speed :)

    int property# { const get; set; }    

    // Written out

    int property#{

            get: {return property;}

            set: {property = value;}

private:

    int proeprty;
};

To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.

[Shachar Shemesh]

On 30/06/14 06:26, Tom Joe wrote:

Instead of the "what for" approach maybe a "why not" would make a more constructive argument.

C++ is currently a very complex language. In an attempt not to have its age show in terms of capabilities, the language carries a whole bunch of rules few people really understand. Never mind Koenig lookup, multiple inheritance constructor calling order and semantics or SFINAE. The average job candidate for senior C++ development positions doesn't know about stuff in C++ that might kill you even if you don't know about them, such as when it is dangerous to throw an exception or why is "explicit" important.

Lately, I'm asking a couple of very simple C++ questions in job interviews. I ask what methods the following class has:

class A {};

I also ask what does adding "virtual" to the destructor does and when it is important.

Very few of the senior and experienced C++ candidates know the answer to those two questions. I don't recall a single confident, correct answer by anyone.

I've had a candidate implement diamond inheritance in his previous job. I asked him about virtual inheritance. He didn't know how it worked. I asked him what they did when they needed it. They, more or less, added "virtual" everywhere until things sort of worked.

Back to your question of "why not?", the answer is "not to make the language any more complicated". If there is no good reason for a change, leave things as they are.

Shachar

[David Krauss]

On 2014–07–12, at 2:09 PM, Shachar Shemesh <sha...@lingnu.com> wrote:

C++ is currently a very complex language. In an attempt not to have its age show in terms of capabilities, the language carries a whole bunch of rules few people really understand. Never mind Koenig lookup, multiple inheritance constructor calling order and semantics or SFINAE.

None of those capabilities are legacy. Most languages are hard to formally understand. Have you looked at the JavaScript spec lately?

Very few of the senior and experienced C++ candidates know the answer to those two questions. I don't recall a single confident, correct answer by anyone.

Nobody reads the job requirements, and “experience” sounds fuzzy anyway. Programmer opportunities attract a random assortment of freeloading riffraff, that’s just the nature of the game.

Back to your question of "why not?", the answer is "not to make the language any more complicated". If there is no good reason for a change, leave things as they are.

Aside from the last few suggestions regarding new punctuation, which I don’t really see the motivation of, this discussion was starting to center on library-only solutions. Such would add nothing to the core language, and only simplify and normalize something that many folks hack through (or search for a copy-pastable hack).

[Tom Joe]

"If there is no good reason for a change, leave things as they are."

Yes; agreed.  But "no good reason" is a matter of view point.

C++ typical access-or implementation has historically been with functions  SetValue() GetValue().  And once again it must be pointed out that Properties only simply the status quo.

For Example a library object has:

DoThis()                            DoThis()

DoThat()                            DoThat()

SetXPos()                          XPos#

SetYPos()                         YPos#

SetZPos()                          ZPos#

GetXPos()

GetYPos()

GetZPos()

There's always the overloading that is probably the easiest way to "simulate" properties

int YPos(int Y){YPos = Y;}

int YPos(){return Y;}

but this really makes source code evaluation even the all the more confusing

if (Ypos()) { YPos(YPos() + 1);}                 // Visually rather confusing

vs if (YPos#) { YPos# = YPos# + 1;}         // We know from syntax '#' YPos is an access-or and therefore may be a point of heavy processing

Just another thought to the posting; Ask experienced C++ applicants, "Do you know what a property is?"

--

---
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.

[Bo Persson]

Tom Joe skrev 2014-07-12 09:11:
> "If there is no good reason for a change, leave things as they are."
>
> Yes; agreed. But "no good reason" is a matter of view point.
> C++ typical access-or implementation has historically been with
> functions SetValue() GetValue().

Not really. How many getX and setX do you find in the standard library?

I see it more common to have pairs of functions, like

int value() const;
void value(int);

if you allow changing the value.

> And once again it must be pointed out
> that Properties only simply the status quo.
>
> For Example a library object has:
> DoThis() DoThis()
> DoThat() DoThat()
> SetXPos() XPos#
> SetYPos() YPos#
> SetZPos() ZPos#
> GetXPos()
> GetYPos()
> GetZPos()
>
> There's always the overloading that is probably the easiest way to
> "simulate" properties
> int YPos(int Y){YPos = Y;}
> int YPos(){return Y;}
>
> but this really makes source code evaluation even the all the more confusing
> if (Ypos()) { YPos(YPos() + 1);} // Visually rather
> confusing
> vs if (YPos#) { YPos# = YPos# + 1;} // We know from syntax '#'
> YPos is an access-or and therefore may be a point of heavy processing

I would do this

if (YPos())
MoveUp(1);

which is even shorter and hides the internal representation better.


Bo Persson

[David Krauss]

On 2014–07–12, at 6:00 PM, Bo Persson <b...@gmb.dk> wrote:

Tom Joe skrev 2014-07-12 09:11:

"If there is no good reason for a change, leave things as they are."

Yes; agreed.  But "no good reason" is a matter of view point.
C++ typical access-or implementation has historically been with
functions  SetValue() GetValue().

Not really. How many getX and setX do you find in the standard library?

The standard library is not a typical C++ library XvD

[Tom Joe]

Not to bring out the point that MoveUp() is completely blind to it's association of the YPos memory since it is not named the same (this was an example context - so point made).  I'll be honest; when starting out learning C++ I had instantly lock-thought "properties" and researching produced a plethora of hacks that were dis-heartening.  Only till some time later I saw a post say "overloading" at which point was a slap in the head *duh*.  Which by all means I feel is a "good-enough" straight forward properties substitute.

That said; along the same lines as properties being dis-liked for being confused with fields;  Using functions can also be confused with wider than memory adjustment functionality.  For some, it may be a dilluted process to think that one function definition gets something while its overload does the exactly the opposite (inverse) and sets it.  This may be thought of as "un-wildly" different behavior.  I think for now though I'm won over as a "good-enough" approach.  I should've become more familiar with C++ before getting all upset about, "Where's the darn properties" :)..

--

--- You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.

To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscribe@isocpp.org.

[Michael Hamilton]

MoveUp is a great method.  Most good method names increase the level of abstraction while allowing the user to express intent rather than focus on twiddling variables.

Part of the reason I don't care too much about properties is that they are a pretty low-level concept that can be over-used to break encapsulation by tying an object's interface too closely to its internal representation.

Obviously I don't think "because it can be misused it shouldn't be in the language".  But I do want to bring this up.

"But one concern I had with this route was how IDE tools with intellisense would differentiate the "." from the "~" list.  If only properties are shown with a "~" is that going to hide important API discovery?" -Tom Joe

I think this is a non-issue.  Vendors would have *more* flexibility in exposing properties and methods and variables as separate concepts than ever before.  It's a common tool behavior to automatically dereference a pointer variable when you type "." by replacing it with "->".  What makes you think a compiler vendor or tool vendor would be incapable of parsing object~ any more than object. or object->?

Given the following class:

class Class {

public:

    int Member~ {

        get: {return Member}

    }

    void Method(){}

    void Method(int param){}

    int MemberPublic;

private:

    int Member;

};

If I were to type:

Class object;

object.M------

The intellisense could easily check all members and offer such a list:

(Method) void Method()

(Method) void Method(int)

(Property:Get) Member

(Variable) int MemberPublic

(Private)-----

(Variable) int Member

Then if you were to select the Member get it could easily substitute the . for ~

I think you vastly underestimate tool vendors and compiler vendors.  They have access to all the information, it's just a matter of presentation.  While not free to implement (nothing is), it certainly wouldn't be impossible or ambiguous.

To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.

[Tom Joe]

"I think this is a non-issue." - I'm sure it is as you've stated; just wanted the implementation part to be under consideration by the experts :).

For some odd reason I still believe it would be a plus for C++ to adopt a "standard" properties approach.
Just as a more clearly defined isolation definition between Public Variable, Property, and Method callers. ( Using syntax difference between field and property Object~Property = 3.0 and Object~>Property = 1.0 )

But with simple overloading doing the API shrinking into-half as keyword elements instead of get/set prefixes; the only benefit left in consideration is syntactics Object.Property(3.0) vs Object~Property = 3.0

Its extremely minor so; for me, If it acts like a property and has the API of a property the setting(value) is just as good/functional as an '=' sign once the concept sets in.

How much abstraction at what architectural level is best practice; I suppose can vary from every particular situation and implementation level.

[Olaf van der Spek]

What about having public const access to members? I think it avoids most of the problems and still improves things significantly.

[openmyso...@gmail.com]

On the other hand I'm not sure that the abuse of a feature is a good argument against that feature.

On Friday, June 6, 2014 1:03:19 AM UTC-4, Miro Knejp wrote:

Am 06.06.2014 06:23, schrieb Andrew Tomazos:
> (...) A little more boilerplate and maybe a little less efficient than
> what the compiler could do for you (...)
>
To me this statement is an indication that maybe language support might
be worth considering, as a portable "zero cost" library solution is not
possible for something that could be done with no overhead by the
compiler. That being said I'm myself not sure whether properties in
general are a good idea as something that looks like an innocent member
access could be hiding an expensive operation without the user being
aware of its implication. The function call syntax at least makes the
reader aware that "something's possibly happening". And that being said
I can't remember how many times I wished I could give a member variable
public read access without having to boilerplate a getter every time.
I'm really not sure on which side of the fence I am here.

[Andrew Tomazos]

On Tue, Jul 15, 2014 at 3:56 AM, <openmyso...@gmail.com> wrote:

On the other hand I'm not sure that the abuse of a feature is a good argument against that feature.

 I would say, in general, that the committee considers very carefully how a proposed feature could be abused and what the consequences of that abuse could be.  This analysis does strongly impact how they vote.  Most voting members come from very large companies that team program very large important codebases, where the cost of potentially dangerous, or even potentially hard to read / follow code, is very high and to which they are very sensitive.

[Tim Yorke]

Properties will improve fundamental abstraction in c++. Currently, we have the situation where a class can have member variables and functions. At the very lowest level of abstraction, these variables and functions can often match directly to the abstraction's "properties " and "methods" and things appears fine.

As the level of abstraction increases, member functions can follow, implementing increasing levels of abstraction. However the member variables fall flat on their faces and instead of being able to carry on directly modeling the "properties" of the object, they are inadequate and we have to start using functions to represent the properties instead (getters and setters). This ends up with a disparity between low-level abstractions and high-level abstractions.

In summary, properties would allow class designers to provide clearer abstractions by removing the necessity to use member functions instead of variables to represent an abstraction's properties as the abstraction level increases. They are able to provide a clear high-level representation without forcing designers down the road of turning their class interfaces into a group of functions, where some happen to represent abstracted properties of some level, and its not clear which (some get/set functions might relate to abstracted properties, other get/set functions might not).

[Tom Joe]

Dido what Tim Yorke states, "improve fundamental abstraction". 

Properties may be considered 'ad-lib' to many and by all means it is.  However, Object-Oriented programming paradigms introduce 'Properties' in general and by-far as an OOP fundamental component of abstraction.  That reason alone (Yes; that is a reason) should make a good basis for adoption of 'Properties' in C++ (An OOP language) just as it would not be expected to be included in C because C is not an OOP language.  The C++ OOP-Model doesn't feel "complete/mature" without property support.

With symbolic upper-level syntax differences between properties vs fields, there doesn't seem to be a good reason not to have a basic standard for the OOP-abstraction component 'Properties' is there?

[David Krauss]

On 2014–08–11, at 3:02 PM, Tom Joe <tgi...@gmail.com> wrote:

> Properties may be considered 'ad-lib' to many and by all means it is. However, Object-Oriented programming paradigms introduce 'Properties' in general and by-far as an OOP fundamental component of abstraction. That reason alone (Yes; that is a reason) should make a good basis for adoption of 'Properties' in C++ (An OOP language) just as it would not be expected to be included in C because C is not an OOP language. The C++ OOP-Model doesn't feel "complete/mature" without property support.

Manager: Marketing data shows that sales would increase 68% if the front window had multicolored tabs.
Engineer: But that would be inconsistent! What kind of users want colorful baubles; do we really want to sell to them at all?

[Tom Joe]

It would be interesting to know which implementation (properties vs overloading) at the language core level would execute faster.  I've kind-of gotta hunch that dis-ambiguating a property would execute quicker than dis-ambiguating an overload thinking along the assumption that properties would only have 2-paths available.

On Mon, Aug 11, 2014 at 6:32 PM, David Krauss <pot...@gmail.com> wrote:

[Boris Rasin]

Here is a good article on the subject of properties in C++:

Saying No To Properties

[Tom Joe]

I always have to laugh at these articles. While trying to prove properties are terrible they always seem to me to UN-intentionally show better their benefits.

Casting - How would you internally cast a field w/o re-implementing a new API whereas if a property has a multi-type return the cast could be encapsulated by it's class definition.
Expression dog.expressHappiness()? wouldn't that even be better expressed as dog.IsHappy = True/False leaving the finer details of doing anything at all up to the class definition.

Call it bad practice; but I've always found it very handy to allow event triggers that are strictly related to a property/data change to happen automatically.  Just as an example; who would really appreciate having to set all the fonts, size, margins etc...  in menus and THEN having to remember to call Doc.ApplySettings(Struct Settings).  When making a setting it seems natural to just apply it automatically and when one wants to retrieve what font is used just retrieve it.  Maybe it's just a thinking method but I've always associated data structures to be part of class design and consider it the benefit of having OOP over Functional programming (No more packing around data everywhere; just keep it where functions are written to use it and ability to create any # of Storage/Functioning compartments (objects).   Print MyData.ToString()

New B BankAccount($0);

B.Widrawl($50);
B.Deposit($50);

B.AccountType = FreeChecking(Enum);

If B.AccountType = FreeChecking Then ....

On Tue, Sep 30, 2014 at 8:38 AM, Tom Joe <tgi...@gmail.com> wrote:

I always have to laugh at these articles. While trying to prove properties are terrible they always seem to me to UN-intentionally show better their benefits.

Casting - How would you internally cast a field w/o re-implementing a new API whereas if a property has a multi-type return the cast could be encapsulated by it's class definition.
Expression dog.expressHappiness()? wouldn't that even be better expressed as dog.IsHappy = True/False leaving the finer details of doing anything at all up to the class definition.

Call it bad practice; but I've always found it very handy to allow event triggers that are strictly related to a property/data change to happen automatically.  Just as an example; who would really appreciate having to set all the fonts, size, margins etc...  in menus and THEN having to remember to call Doc.ApplySettings(Struct Settings).  When making a setting it seems natural to just apply it automatically and when one wants to retrieve what font is used just retrieve it.  Maybe it's just a thinking method but I've always associated data structures to be part of class design and consider it the benefit of having OOP over Functional programming (No more packing around data everywhere; just keep it where functions are written to use it and ability to create any # of Storage/Functioning compartments (objects).   Print MyData.ToString()

New B BankAccount($0);

B.Widrawl($50);
B.Deposit($50);

B.AccountType = FreeChecking(Enum);

If B.AccountType = FreeChecking Then ....

[Olaf van der Spek]

How's that a good article?
I don't think it's good at all. It's basically saying: don't use
properties as public data members.

On Tue, Sep 30, 2014 at 2:29 PM, Boris Rasin <rasin...@gmail.com> wrote:
> Here is a good article on the subject of properties in C++:
>
> Saying No To Properties
>

> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--
Olaf

[Douglas Boffey]

On Tuesday, 30 September 2014 15:49:36 UTC+1, Tom Joe wrote:

 

Call it bad practice; but I've always found it very handy to allow event triggers that are strictly related to a property/data change to happen automatically.  Just as an example; who would really appreciate having to set all the fonts, size, margins etc...  in menus and THEN having to remember to call Doc.ApplySettings(Struct Settings).  When making a setting it seems natural to just apply it automatically and when one wants to retrieve what font is used just retrieve it.  Maybe it's just a thinking method but I've always associated data structures to be part of class design and consider it the benefit of having OOP over Functional programming (No more packing around data everywhere; just keep it where functions are written to use it and ability to create any # of Storage/Functioning compartments (objects).   Print MyData.ToString()

What?  Surely if properties were to be allowed, using some sort of trigger mechanism seems inefficient to me.  As far as I’m concerned, the only realistic way would be to implement property handlers, i.e. to map it to a setter/getter. 

[Boris Rasin]

It says don't use public data members, properties or not. And that, I think, is a pretty good practice.

[Tom Joe]

Actually I personally am quite curious as to this claim "don't use public data members" - I've heard it time and time again from many different sources but have often wondered where it originates from or what exactly is it's intention.  While I can relate to the versatility of separating user data from functional code (say XML file as input) - if everything is XML then what exactly was the point of the OOP paradigm (Allowing data and function to be encapsulated together) to begin with?  Just stuff all the XML attributes into a function and stick with functional programming with namespaces.

I'm sure I'm missing something here - but I have yet to have someone offer up a good explanation.