220 5978 <1797e481-d39e-4ba0-b797-6c0a8db862aa@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nick Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Properties Syntax Date: Thu, 29 Aug 2013 08:06:05 -0700 (PDT) Lines: 485 Approved: news@gmane.org Message-ID: <1797e481-d39e-4ba0-b797-6c0a8db862aa@isocpp.org> References: <5e23a0e9-2bd9-4f62-aa83-47bea8144eae@isocpp.org> <5458c2e0-2e03-444e-a34d-4960a07b94ad@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13_16005785.1377788765423" X-Trace: ger.gmane.org 1377788769 31511 80.91.229.3 (29 Aug 2013 15:06:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Aug 2013 15:06:09 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC42HSUOVYGBBXWG7WIAKGQEAPN2CRQ@isocpp.org Thu Aug 29 17:06:12 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VF3nT-0000Q4-HX for gclcip-std-proposals@m.gmane.org; Thu, 29 Aug 2013 17:06:07 +0200 Original-Received: by mail-vc0-f200.google.com with SMTP id hf12sf568545vcb.7 for ; Thu, 29 Aug 2013 08:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=9DWObnNGGoLzTSJHnk/8+HrpjA8VNFRvXdqncdiArXI=; b=r42Ok1LSyMqv/GdqVVzlFMOVCRYz1GojajGD27vnNiVVW8bi8g4t6i3nl7X07wznNp v5mJDjKlx/e1c/IHt0GMfPT3KKYQ0SzLE/SIUKTRLq8quZbJMrx3xynwzUnrmCIQQ4QA mCYKBs4xCE6/DhU8tO64vsR/SMqTriAaiTKXBtSh7S1nZAFPVGzfsP/sNrlS393LRh5r vc9ScG4dqnvWgGe0KYJ9/9vK3uu0KfWugo/roTY8N1Ba7su5qXwN3QDZAe/etSwt2WR4 zIozO2Br9fx3t34UFTXvHLe/izrxji379t9Qz/pxf/DLJSPCiv7ShujfVIgUKPdV4IQX StFg== X-Received: by 10.58.33.36 with SMTP id o4mr356653vei.28.1377788766675; Thu, 29 Aug 2013 08:06:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.49.42 with SMTP id r10ls867286qen.86.gmail; Thu, 29 Aug 2013 08:06:06 -0700 (PDT) X-Received: by 10.49.12.162 with SMTP id z2mr110104qeb.14.1377788766048; Thu, 29 Aug 2013 08:06:06 -0700 (PDT) In-Reply-To: X-Original-Sender: nicolas.jinchereau@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:5978 Archived-At: ------=_Part_13_16005785.1377788765423 Content-Type: text/plain; charset=ISO-8859-1 On Thursday, 29 August 2013 08:06:31 UTC-4, Ville Voutilainen wrote: > > > > On 29 August 2013 14:54, Nicol Bolas >wrote: > >> >> >>> seems silly to dismiss a proposal because of something that *might*happen in the future. >>>> >>> >>> Well, there has been no such dismissal, so I don't see what you're >>> complaining about. >>> >> >> *ahem*: "Do people think properties should be a language feature, when >> they are seemingly just one of the many >> >> things compile-time reflection can provide?" >> >> That sounds dismissive. Since you're dismissing properties as "one of the >> many things compile-time reflection can provide". That sounds very much >> like, "wait for reflection". Which is dismissive. >> > > Feel free to continue putting words into other people's mouths. That's a > question, not a dismissal. Anything > else you read into it is your own paranoia. > > >> >> Or, let me put it this way: >> >> There is no way to make properties as a hack, either via some library >> type or via reflection, and still have it fulfill all of these >> requirements, such that making a property: >> >> 1: Is easy for new C++ users to learn to use. >> >> 2: Is easy for new C++ users to read in other people's code. >> >> 3: Is reasonably compact in syntax. >> >> 4: Doesn't change the nature of the type on which it is placed. >> >> 5: Doesn't break the abstraction. >> >> 6: Has all of the features of properties in other languages that are >> appropriate to C++. >> > > There's no way? Based on what evidence? Has this been explored by some > proposal I'm unaware of? > You may be right, which to me would indicate that properties aren't worth > their cost, especially > if it's common that the get/set functions need to be written anyway to > cover cases where they aren't > just trivial operations. > > > >> >> You may be able to make it *function* with reflection. But it won't ever >> be a *good* feature that people will want to use and teach others to >> use. With reflection, it'll merely be a curiosity that maybe some advanced >> C++ programmers will provide. >> >> template decltype(auto) operator->() >>>>> { >>>>> static if (s == "x") { >>>>> return y; >>>>> } else { >>>>> static_assert(false, "no such member"); >>>>> } >>>>> } >>>>> }; >>>>> >>>>> The use is then >>>>> >>>>> X x; >>>>> int foo = x.x; >>>>> >>>>> or more verbosely, >>>>> X x; >>>>> int foo = std::reflection::member<**compil**etimestring("x")>(x); >>>>> >>>> >>>> OK, where's the part that lets you do `x.x = 4`? Or `x.x = k`, where k >>>> is a type that is *not* implicitly convertible to x.x's type? Or the >>>> >>> >>> In the part where I return a reference to y. >>> >> >> Except that the reference to `y` returns a `Type&` (where `Type` is `y`'s >> type). And as I stated, if `k` is not *implicitly* convertible to >> `Type`, then doing `x.x = k` will not work. The actual properties feature >> would allow the user to specify multiple `set` methods, each of which could >> take *any* type. >> > > Oh. I must admit I'm unaware of an existing property system that allows > multiple setters. > > >> >> Also, what of the possibility where there is no actual `y` at all? That's >> a very common use of properties: to create getters/setters for a "variable" >> that doesn't exist. Or that you don't want to expose `Type&`? Do you have >> to create some proxy type to do the actual getting/setting? Because that's >> not sounding like a good feature anymore. >> > > No. You can set thin air if you want, or return temporaries. > > >> part that lets you have multiple properties with different types (say, an >>>> int and a float)? Or the part that makes this increasing mass >>>> >>> >>> There's no restriction against having multiple properties with different >>> types in that pseudocode. >>> >> >> I can't imagine how that could possibly work, since your `operator->` >> can only return a single type. Not unless "multiple properties" means >> "multiple properties that all happen to use the same type". And you can't >> declare two of these `operator->` things unless they take different >> parameters. Which they don't. >> > > I can declare multiple specializations for it, since it's a template. I > also expect eventually to have a run-time counterpart > for it that will be called if none of the templates match. That would be > the way to plug run-time reflection on top of it. > > >> >> Not unless you mean to use a concept or something to conditionally >> activate or deactivate different instantiations based on ``. Because >> that's not helping the case for this being a good idea; that just makes the >> complex feature even moreso. >> > > If people choose to do that, it's up to them. It's not the fundamental > technique. > > >> >> Why are people so willing to settle for this kind of hackery? Have we >>>> learned *nothing* from the `enable_if` horrors? If this is an >>>> >>> >>> Because sometimes people are willing to strive for a general facility >>> that may not be optimal for one of the cases >>> it covers, like properties, when the general facility provides much more >>> than just a single feature. >>> >> >> So what if they are? That doesn't explain why a hack is better than a >> real feature. Or should we abandon concepts since `enable_if` and such >> hackery can get us there anyway? >> > > You keep speaking of "hacks". The reason behind such a "hack" that is the > programmable dispatch is the case > where you have N properties/members in a subobject, and you want your > containing wrapper to mirror those. > With your properties, you'll write N properties. With reflection, you > write a single dispatching function that forwards > the member query to the subobject. > > > >> >> That presupposes the idea that if we had such reflection, we necessarily >> *shouldn't* have real properties, because you could get maybe most of >> properties working in a much less easily understood, hacky, and less >> readable way. That no IDE would ever be able to understand without having a >> full-fledged compiler built into it. >> >> That the general facility might allow 80% of some idea to be implemented >> doesn't mean that the 20% it doesn't work for stops being important. Or >> that the pain of using the facility in that way should be ignored. >> > > The real question is whether this 20% is important enough that a more > general facility can't cover it sufficiently > well. And do read what Richard said, perhaps it would be better to make > language changes that make properties > as library features more feasible, rather than just putting in a core > language property feature. > > >> I'm not saying that we shouldn't have reflection. I'm saying that >> reflection is no substitute for properties if that's a feature we want. >> > > Again, based on what evidence/exploration? I'd like to see some actual > analysis rather than sweeping statements. > *"Oh. I must admit I'm unaware of an existing property system that allows multiple setters."* The D language property system(which I made reference to in my first post) does: import std.stdio; struct Foo { @property int data() { return m_data; } @property int data(int value) { writeln("set int"); return m_data = value; } @property int data(float value) { writeln("set float"); return m_data = cast(int)value; } private: int m_data; } void main() { Foo foo; foo.data = 1; foo.data = 2.0f; writef("Result %s\n", foo.data); } output: set int set float 2 As far as this function goes, which I agree is quite imaginary, I don't see how it would provide a better, if any, solution to the problems that properties solve. *"template decltype(auto) operator->()"* -- --- 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. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_13_16005785.1377788765423 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thursday, 29 August 20= 13 08:06:31 UTC-4, Ville Voutilainen wrote:



On 29 August 2013 14:54, Nicol Bolas <jmck...@gmail.com> wrote:
 
seems silly to dismiss a proposal because of somethin= g that might happen in the future.
=
Well, there has been no such dismissal, so I don't see what = you're complaining about.

*ahem*: "Do people thin= k properties should be a language feature, when they are seemingly just one= of the many

things compile-time reflection can provide?"

That sounds dismissive. Since you're dismissing properties as "on= e of the many things compile-time reflection can provide". That sounds very= much like, "wait for reflection". Which is dismissive.

Feel free to continue putting = words into other people's mouths. That's a question, not a dismissal. Anyth= ing
else you read into it is your own paranoia.
 

Or= , let me put it this way:

There is no way to make properties as a ha= ck, either via some library type or via reflection, and still have it fulfi= ll all of these requirements, such that making a property:

1: Is easy for new C++ users to learn to use.

2: Is easy for new= C++ users to read in other people's code.

3: Is reasonably compact = in syntax.

4: Doesn't change the nature of the type on which it is p= laced.

5: Doesn't break the abstraction.

6: Has all of the features of = properties in other languages that are appropriate to C++.
<= /blockquote>

There's no way? Based on what evidence? Has= this been explored by some proposal I'm unaware of?
You may be right, which to me would indicate that properties are= n't worth their cost, especially
if it's common that the get/set functio= ns need to be written anyway to cover cases where they aren't
just trivial operations.

 

You may be able to make it func= tion with reflection. But it won't ever be a good feature that p= eople will want to use and teach others to use. With reflection, it'll mere= ly be a curiosity that maybe some advanced C++ programmers will provide.
    te= mplate<compile_time_string s> decltype(auto) operator-><s>()=
    {
      =   static if (s =3D=3D "x") {
          &nbs= p; return y;
        } els= e {
         &nb= sp;  static_assert(false, "no such member");
  = ;      }
    }
};

The use is then

X x;
int foo =3D x.x;
or more verbosely,
X x;
int foo =3D std::reflection::member<compiletimestring= ("x")>(x);

OK, where's the pa= rt that lets you do `x.x =3D 4`? Or `x.x =3D k`, where k is a type that is = *not* implicitly convertible to x.x's type? Or the

In the part where I return a referen= ce to y.

Except that= the reference to `y` returns a `Type&` (where `Type` is `y`'s type). A= nd as I stated, if `k` is not implicitly convertible to `Type`, then= doing `x.x =3D k` will not work. The actual properties feature would allow= the user to specify multiple `set` methods, each of which could take an= y type.

Oh. I must admit I'm unaware o= f an existing property system that allows multiple setters.
 

Also, what of the possibility where there is no a= ctual `y` at all? That's a very common use of properties: to create getters= /setters for a "variable" that doesn't exist. Or that you don't want to exp= ose `Type&`? Do you have to create some proxy type to do the actual get= ting/setting? Because that's not sounding like a good feature anymore.

No. You can set thin air if yo= u want, or return temporaries.


part that lets you have multiple properties with diff= erent types (say, an int and a float)? Or the part that makes this increasi= ng mass

There's no restriction against havin= g multiple properties with different types in that pseudocode.

I can't imagine how that could p= ossibly work, since your `operator-><s>` can only return a single = type. Not unless "multiple properties" means "multiple properties that all = happen to use the same type". And you can't declare two of these `operator-= ><s>` things unless they take different parameters. Which they don= 't.

I can declare multiple special= izations for it, since it's a template. I also expect eventually to have a = run-time counterpart
for it that will be called if none of the templates= match. That would be the way to plug run-time reflection on top of it.
 

No= t unless you mean to use a concept or something to conditionally activate o= r deactivate different instantiations based on `<s>`. Because that's = not helping the case for this being a good idea; that just makes the comple= x feature even moreso.

If people choose to do that, i= t's up to them. It's not the fundamental technique.
 

Why are people so willing to settle for this kind of = hackery? Have we learned nothing from the `enable_if` horrors? If th= is is an

Because sometimes peo= ple are willing to strive for a general facility that may not be optimal fo= r one of the cases
it covers, like properties, when the general facility provides much more th= an just a single feature.
So what if they are? That doesn't explain why a hack is better than a rea= l feature. Or should we abandon concepts since `enable_if` and such hackery= can get us there anyway?

You keep speaking of "hacks". = The reason behind such a "hack" that is the programmable dispatch is the ca= se
where you have N properties/members in a subobject, and you want your= containing wrapper to mirror those.
With your properties, you'll write N properties. With reflection= , you write a single dispatching function that forwards
the member query= to the subobject.

 

That presupposes the idea that if we had such ref= lection, we necessarily shouldn't have real properties, because you = could get maybe most of properties working in a much less easily understood= , hacky, and less readable way. That no IDE would ever be able to understan= d without having a full-fledged compiler built into it.

That the general facility might allow 80% of some idea to be implemente= d doesn't mean that the 20% it doesn't work for stops being important. Or t= hat the pain of using the facility in that way should be ignored.

The real question is whether t= his 20% is important enough that a more general facility can't cover it suf= ficiently
well. And do read what Richard said, perhaps it would be bette= r to make language changes that make properties
as library features more feasible, rather than just putting in a core langu= age property feature.


I'm not saying that we shouldn't have reflection. I'm saying that = reflection is no substitute for properties if that's a feature we want.

Again, based on what evidence/exp= loration? I'd like to see some actual analysis rather than sweeping stateme= nts.


"Oh. I must admit I'm unaware of an existing property system that allow= s multiple setters."

The D language proper= ty system(which I made reference to in my = first post) does:
=

im= port std.stdio;

struct Foo
{
    @property int data() {
        return m_data;
    }
=     @property int data(int value) {
        writeln("set int");
        return m_data =3D value;
    }
    @property int data(float value) {
        writeln("set float");
        return m_data =3D cast(int= )value;
    }
    private: int m_data;
}

void main()
{
    Foo foo;
    foo.data =3D 1;
&= nbsp;   foo.data =3D 2.0f;
  &= nbsp; writef("Result %s\n", foo.data);
}=

output:
set int
set float
2

As far a= s this function goes, which I agree is quite imaginary, I don't see how it = would provide a better, if any, solution to the problems that properties so= lve.

"te= mplate<compile_time_string s> decltype(auto) operator-><s>()= "

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