July 23, 2009
Lutger wrote:

> There have been a lot of discussions on this topic in the past but I can't recall any conclusions. Perhaps some brave soul would dare to write a DIP on properties?

Property DIPs have been offered in the newsgroup in the past, only before they were called DIPs. I also offered a possible design:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81759

Feel free to modify and/or DIPify it.

-- 
Michiel Helvensteijn

July 23, 2009
Walter Bright, el 23 de julio a las 12:11 me escribiste:
> >>>* Tuples (no dedicated syntax, no parallel assignment, no non-flattening tuples without workarounds, no returning tuples)
> >>The flattening thing is a problem. The rest can be done with better library support.
> >You cannot get a dedicated syntax with library support.
> 
> Of course that's true, but why is a dedicated syntax better than Tuple!( ...) ?

When I see this, I think about this:

for (std::vector<int>::const_iterator i = v.begin(); i != v.end(); ++i) {
	int x = *i;
	...
}

Why is foreach (x; v) ... better than the former?

The problem is, if is hard to write, or ugly to read, people won't use it, or will use it less. In Python tuples are easy to read and write, so people use them everywhere and they are really useful (especially for FP-style programming, where is more common to return multple values).

I think that library tuple *implementation* is a great idea (like library dynamic and associative arrays implementations), but not having support in the language for tuples is bad (like it will be not to have dynamic and associative arrays). I think the 3 are very fundamental types and deserves language support.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
<original> [Penis Uptime: 2days 13hrs 59mins 35secs]
<Yapa> viagra? :)
<original> yea, 20 pills
July 23, 2009
On Thu, Jul 23, 2009 at 1:53 PM, Michiel Helvensteijn<m.helvensteijn.remove@gmail.com> wrote:
> Lutger wrote:
>
>> There have been a lot of discussions on this topic in the past but I can't recall any conclusions. Perhaps some brave soul would dare to write a DIP on properties?
>
> Property DIPs have been offered in the newsgroup in the past, only before they were called DIPs. I also offered a possible design:
>
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81759
>
> Feel free to modify and/or DIPify it.

"""
I've always thought properties should work somewhat like this:

property int length {
    get() { return this.len; }
    set(newLen) { this.len = newLen; }
}
"""

I'm curious.  Is it just a coincidence that how you've "always thought" happens to look a lot like C# properties?   Or did you mean to say "Ever since I saw how C# does properties I've thought...."?

In any event I think a problem with this is that for D's simple grammar to remain simple and context free, get and set would both have to be made keywords in the language.  Can a compiler guru confirm that?  Not a big issue, but introducing 3 keywords for this one feature will be a tough sell.   Perhaps just

property int length {
    () { return this.len; }
    (newLen) { this.len = newLen; }
}

would be enough.  Maybe I'm wrong about get/set being an issue, though.

--bb
July 23, 2009
Bill Baxter wrote:

> Not a big issue, but introducing 3 keywords for this one
> feature will be a tough sell.
> --bb

At least it's not 5 like vb.net, but that beast already has 150 keywords so I guess a couple more doesn't matter that much :)


July 23, 2009
On 2009-07-23 13:59:46 -0400, Walter Bright <newshound1@digitalmars.com> said:

> Michel Fortin wrote:
>> If I'm not mistaken, both your D1 and D2 installer install at the same location and they will overwrite each other. I'd much prefer if D2 and D1 could coexist without having to go with a special installer or custom installation instructions. Otherwise it'll be hard for me to offer the choice between D1 and D2 in Xcode (and I certainly do want that choice to be available).
>> 
>> Thoughts?
> 
> I've been switching the directories to {dmd, dmd2} so they can coexist.

I know. But the OS X installer I see on dsource doesn't seem to reflect that: it always install at /usr/share/dmd/ (and /usr/share is a stange choice too).

Now that I look at it, it seems to predate the switch to separate directories.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

July 23, 2009
On Thu, 23 Jul 2009 17:13:13 -0400, Bill Baxter <wbaxter@gmail.com> wrote:

> In any event I think a problem with this is that for D's simple
> grammar to remain simple and context free, get and set would both have
> to be made keywords in the language.  Can a compiler guru confirm
> that?  Not a big issue, but introducing 3 keywords for this one
> feature will be a tough sell.   Perhaps just
>
> property int length {
>     () { return this.len; }
>     (newLen) { this.len = newLen; }
> }
>
> would be enough.  Maybe I'm wrong about get/set being an issue, though.

I think you might be wrong.  operator functions like opAdd are not keywords, but are treated specially by the compiler.  The compiler would probably just change the get and set functions into mangled symbols that would never be generated from a normal function, so no keywords would be required.

-Steve
July 23, 2009
On Thu, Jul 23, 2009 at 2:19 PM, Lutger<lutger.blijdestijn@gmail.com> wrote:
> Bill Baxter wrote:
>
>> Not a big issue, but introducing 3 keywords for this one
>> feature will be a tough sell.
>> --bb
>
> At least it's not 5 like vb.net, but that beast already has 150 keywords so I guess a couple more doesn't matter that much :)

I do think it would be justifiable to add one more keyword for real properties, just not three.  If the get/set could somehow be context keywords then that would be nice.  I know these sorts of context keywords are ok in D's grammar    version(Foo) and   foreach(reverse) was bandied about as being acceptable since they have a clear contextual scope, just not sure if get/set inside a property block would qualify.

--bb
July 23, 2009
Bill Baxter wrote:

> """
> I've always thought properties should work somewhat like this:
> 
> property int length {
>     get() { return this.len; }
>     set(newLen) { this.len = newLen; }
> }
> """
> 
> I'm curious.  Is it just a coincidence that how you've "always thought" happens to look a lot like C# properties?   Or did you mean to say "Ever since I saw how C# does properties I've thought...."?

Nope. Never used C#, never seen it. I just think about language design a lot, and this is what I came up with. From that newsgroup thread, it seems that they are still quite different from C# properties.

> In any event I think a problem with this is that for D's simple grammar to remain simple and context free, get and set would both have to be made keywords in the language.

I don't think so. They can just be identifiers with special meaning. If you look a bit further down the thread, I suggest adding the 'auto' keyword where the missing types are now. Perhaps that helps.

In fact, in the design of my own language, those names have special meaning for all types:

get(x) (or x.get()) returns x itself.

set(x, v) (or x.get(v)) assigns v to x.

If you specify them in a property, you're just overriding their meaning for the underlying type of the property, just like you can override other member-functions. Another upside is that you can always count on these functions existing for every type and you can pass them around as functions/delegates.

-- 
Michiel Helvensteijn

July 23, 2009
On Thu, Jul 23, 2009 at 2:25 PM, Steven Schveighoffer<schveiguy@yahoo.com> wrote:
> On Thu, 23 Jul 2009 17:13:13 -0400, Bill Baxter <wbaxter@gmail.com> wrote:
>
>> In any event I think a problem with this is that for D's simple grammar to remain simple and context free, get and set would both have to be made keywords in the language.  Can a compiler guru confirm that?  Not a big issue, but introducing 3 keywords for this one feature will be a tough sell.   Perhaps just
>>
>> property int length {
>>    () { return this.len; }
>>    (newLen) { this.len = newLen; }
>> }
>>
>> would be enough.  Maybe I'm wrong about get/set being an issue, though.
>
> I think you might be wrong.  operator functions like opAdd are not keywords, but are treated specially by the compiler.  The compiler would probably just change the get and set functions into mangled symbols that would never be generated from a normal function, so no keywords would be required.

That makes sense.

Maybe Walter would like to take this opportunity to plug his upcoming compiler building seminar for us compiler ignoramuses.  :-)

--bb
July 23, 2009
Michiel Helvensteijn wrote:

> set(x, v) (or x.get(v)) assigns v to x.

Small correction: x.set(v)

-- 
Michiel Helvensteijn

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18