July 25, 2009
Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> Ary Borenszweig wrote:
>>> Maybe what scares Walter is a whole new syntax for properties. If at least you could say which functions are properties and which are not, that would be a small change and it'll make it possible for other things. Something like:
>>>
>>> int property foo(); // getter
>>> int property foo(int value); // setter
>>
>> My proposal requires no new keywords and no new syntax:
>>
>> int getfoo(); // getter
>> int setfoo(int); // setter
> 
> This is pretty clean, and in keep with the opXxx approach. Actually how about defining property foo by defining opGet_foo and opSet_foo.
> 
> Andrei

Actually, if this became the "official" way of doing properties, that would solve the IDE and debugger issues and (hopefully) the parens thing.

Which leaves only one issue: that writing properties violates DRY.  So I wrote a basic Property generator.

Full source is here: http://gist.github.com/154755

I know people hate mixins, but this approach would give us discoverability and a slightly terser syntax, without having to actually introduce new language syntax.

And maybe if D ends up with enough of these mixins being used as standard, it'll spur Walter into adding macros.  :D

Examples from the code:

struct S
{
    mixin
    (
        // Default accessor property with automatic private storage.
        Property!(int, "bar")

        // Public read-only w/ auto storage
        ~Property!(int, "baz", null, "private")

        // Public read-only with default
        ~Property!(int, "bop = 42", null, "private")

        // Read-only
        ~Property!(int, "qux", null, "-")

        // Fully custom; no auto storage created
        ~Property!(int, "zyz",
        q{
            return 7;
        },
        q{
            // Note "magic" value argument
            writefln("Set zyz to: %s", value);
        })

        // Fully custom with private setter and auto storage
        ~Property!(int, "gfh",
        q{
            // Public here is optional
            public
            {
                return storage/100;
            }
        },
        q{
            private
            {
                storage = value*100;
            }
        })
    );
}
July 25, 2009
Jesse Phillips, el 25 de julio a las 03:38 me escribiste:
> > But you should support multple assignment, for example. If you don't, you don't have real tuple support, just a toy tuple emulation.
> 
> Tuples have nothing to do with multiple assignment, it is just something languages tend to provide.

It has, providing tuples without that generally doesn't need language support, like D or C++ tuples. When you have multiple assignment, you can fully use the power of tuples, if not, it's just syntax sugar for structs, or some kind of limited list.

Tuples are much more useful when are a *language construct*.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Dale tu mano al mono, pero no el codo, dado que un mono confianzudo es
irreversible.
	-- Ricardo Vaporeso. La Reja, Agosto de 1912.
July 25, 2009
Walter Bright Wrote:

> Steven Schveighoffer wrote:
> > On Fri, 24 Jul 2009 14:10:59 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
> >> That's my problem with properties as a distinct syntax - they don't have distinct uses or behaviors.
> > 
> > If you delineate what can be called how, then you elminate syntax ambiguities from occurring, and eliminate bizarro cases of syntax.  The difficulty is that the "human meaning" of a property is different than the human meaning of a function.  To the compiler, they're all functions, so you as the compiler writer aren't seeing that they are different.  I think we all agree that writefln = "hi"; makes absolutely no sense to a person.  But it makes complete sense to the compiler, because it has no idea what the word "writefln" means to a person.
> 
> But when I suggest a restriction on properties, I get complaints that someone might want to have them do what functions do. So I fail to see what rule distinguishes them from functions, even for people.

The only thing that properties can't do that functions can is be called with parentheses.  The only thing that functions cannot do that properties can is be called without parentheses (assuming properties are separated from functions)

I fail to see any issues there.  Where are these complaints you speak of?  I've not seen any.

> > It's the exact same reason + is not the concatenation operator. Semantically, making + concatenate two strings together would be completely unambiguous from adding two integers together because strings do not define addition, and integers do not define concatenation.  From your own documentation, someone seeing "10" + 3 might think that he would get 13 or "103".  Even if the compiler defines what "should" happen, and the rules are unambiguous, it looks incorrect to the user.
> 
> Using + for concatenation is syntactically ambiguous with vector addition.

OK, but assuming you didn't have vector addition (which you didn't have up until a few months ago), then how is this a different scenario than the property issue?  Isn't it also ambiguous when you want to call a delegate/function returned from a property?

Besides this, I like what another poster brought up better -- array indexing is the same as functions too, they take a single parameter, and return a value.  So why do we have two different syntaxes for arrays and functions?  Why do we have a special syntax for opIndex but no special syntax for properties?  They're all functions, right?

-Steve
July 25, 2009
Leandro Lucarella wrote:
> It has, providing tuples without that generally doesn't need language support, like D or C++ tuples. When you have multiple assignment, you can fully use the power of tuples, if not, it's just syntax sugar for structs, or some kind of limited list.

From the Boost.Tuple documentation:

  int i; char c; double d;
  tie(i, c, d) = make_tuple(1,'a', 5.5);
  std::cout << i << " " <<  c << " " << d;

So C++ tuples *do* support multiple assignment, even without language support.  Still not as nice as the Python syntax, though.


-- 
Rainer Deyke - rainerd@eldwood.com
July 25, 2009
On Sat, Jul 25, 2009 at 01:20:33PM -0600, Rainer Deyke wrote:
> >From the Boost.Tuple documentation:
> 
>   int i; char c; double d;
>   tie(i, c, d) = make_tuple(1,'a', 5.5);
>   std::cout << i << " " <<  c << " " << d;
> 
> So C++ tuples *do* support multiple assignment, even without language support.  Still not as nice as the Python syntax, though.

I think I like that.


-- 
Adam D. Ruppe
http://arsdnet.net
July 25, 2009
On Sat, Jul 25, 2009 at 02:15:00PM -0300, Leandro Lucarella wrote:
> if not, it's just syntax sugar for structs,
> or some kind of limited list.

Interestingly, I've been looking at tuples almost entirely as "anonymous structs", if you will. Perhaps this is another bias preventing me from seeing the big advantage of the other syntax.

-- 
Adam D. Ruppe
http://arsdnet.net
July 25, 2009
Rainer Deyke, el 25 de julio a las 13:20 me escribiste:
> Leandro Lucarella wrote:
> > It has, providing tuples without that generally doesn't need language support, like D or C++ tuples. When you have multiple assignment, you can fully use the power of tuples, if not, it's just syntax sugar for structs, or some kind of limited list.
> 
> From the Boost.Tuple documentation:
> 
>   int i; char c; double d;
>   tie(i, c, d) = make_tuple(1,'a', 5.5);
>   std::cout << i << " " <<  c << " " << d;
> 
> So C++ tuples *do* support multiple assignment, even without language support.  Still not as nice as the Python syntax, though.

But you have to split declaration from initialization. That's not nice.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Yo soy Peperino Mártir Sanito, yo soy aquel, que come los flanes
serenito.
	-- Peperino Pómoro
July 26, 2009
On Fri, 24 Jul 2009 21:36:53 -0400, Daniel Keep <daniel.keep.lists@gmail.com> wrote:


> There's also the argument for debuggers being able to automatically
> display properties; I think this one is fairly borderline since if I was
> writing a debugger, it would only *automatically* display the result of
> pure functions, property or not.
>

I agree with this.  A property should only be callable by the debugger if it is pure.  I don't think properties should be required to be pure, because pure functions are far too restrictive for properties.

Note that in other debuggers which debug code that is fully runtime inspectable, such as Visual C#'s debugger, the IDE will tell you if evaluating a property will result in an object change, so they must mark the property somehow.

I think the other reasons for having property syntax are much more important than this.

-Steve
July 26, 2009
On Fri, 24 Jul 2009 22:58:33 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Rainer Deyke wrote:
>> Ary Borenszweig wrote:
>>> Maybe what scares Walter is a whole new syntax for properties. If at
>>> least you could say which functions are properties and which are not,
>>> that would be a small change and it'll make it possible for other
>>> things. Something like:
>>>
>>> int property foo(); // getter
>>> int property foo(int value); // setter
>>  My proposal requires no new keywords and no new syntax:
>>  int getfoo(); // getter
>> int setfoo(int); // setter
>
> This is pretty clean, and in keep with the opXxx approach. Actually how about defining property foo by defining opGet_foo and opSet_foo.

I would be OK with defining properties any of these ways.  Although the definition of properties is ugly, it's the usability and meaning which are most important.  Using opGet and opSet is probably the better method, since nobody is going to name their normal members that way.

In fact, I think C++.Net did something similar in earlier versions.  Something like to call or define properties you defined the function get_propname and set_propname.

-Steve
July 27, 2009
Fri, 24 Jul 2009 16:58:50 -0500, Andrei Alexandrescu wrote:

>>>> deterministic destructors,  arbitrary copy constructors, and optional lack of default constructor.
>>> Struct have that except for default constructor. In D, currently default constructors cannot execute code. This is a limitation that we might need to address, although it has some advantages.
>> 
>> There are things that copy constructors can do that the post-blit operator can't do.
> 
> Yes, mostly wrong things. I think it would be a huge loss if D copied C++'s model.

This means that structs cannot hold on external resources, ever:

    struct RAII {...}
    var a = RAII("foo");
    var b = RAII("bar");
    a = b; // you just leaked a and corrupted b