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

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

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

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 :)

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/

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

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

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

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