July 27, 2009 Re: Reddit: why aren't people using D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sergey Gromov | Sergey Gromov wrote:
> 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
You may be making a confusion between assignment and copy construction.
Andrei
|
July 27, 2009 Re: Reddit: why aren't people using D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | Sun, 26 Jul 2009 21:23:35 -0500, Andrei Alexandrescu wrote:
> Sergey Gromov wrote:
>> 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
>
> You may be making a confusion between assignment and copy construction.
Sure I'm confusing them, silly me.
The only thing copy-construction is useful for is implementing move semantics, think std::auto_ptr. Seems like everything else can be done in post-blit.
The inability to overload opAssign(typeof(this)) is a blocker for robust
RAII though.
|
July 27, 2009 Re: Comma expressions must die [Was: Reddit: why aren't people using | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | Adam D. Ruppe:
> Why is dedicated syntax for comma expressions better than commaExpr(...)?
>What do you propose we do about the commas in loops? Breaking them would be a pretty big change to the C folks.<
Disallowing bad usages of commas is a starting point. for() can become a special case. Handy syntax for tuple unpacking is useful in many situations, look at Python code.
Bye,
bearophile
(Late answer, sorry, I was away)
|
July 27, 2009 Re: Reddit: why aren't people using D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
> Ary Borenszweig wrote:
>> Maybe what scares Walter is a whole new syntax for properties.
>
> It doesn't scare me. It's trivial to add more syntax.
>
> It's just that D is complex enough - there needs to be some very good reasons for adding more syntax that has apparently zero semantic information that would be different from the usual function syntax.
OK, so you don't like the idea of adding dedicated properties.
What is *your* solution to forbidding abuses like this:
writefln = "hi";
???
-Steve
|
July 27, 2009 Re: Reddit: why aren't people using D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Mon, Jul 27, 2009 at 7:13 AM, Steven Schveighoffer<schveiguy@yahoo.com> wrote: > On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright <newshound1@digitalmars.com> wrote: > >> Ary Borenszweig wrote: >>> >>> Maybe what scares Walter is a whole new syntax for properties. >> >> It doesn't scare me. It's trivial to add more syntax. >> >> It's just that D is complex enough - there needs to be some very good reasons for adding more syntax that has apparently zero semantic information that would be different from the usual function syntax. > > OK, so you don't like the idea of adding dedicated properties. > > What is *your* solution to forbidding abuses like this: > > writefln = "hi"; > > ??? > I think his suggestion was the Java-style approach -- special naming convention for get/set functions: int opGet_foo() { return foo_; } void opSet_foo(int foo) { foo_ = foo; } private: int foo_; --bb |
July 27, 2009 Re: Reddit: why aren't people using D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | On Mon, 27 Jul 2009 13:23:42 -0400, Bill Baxter <wbaxter@gmail.com> wrote:
> On Mon, Jul 27, 2009 at 7:13 AM, Steven
> Schveighoffer<schveiguy@yahoo.com> wrote:
>> On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>
>>> Ary Borenszweig wrote:
>>>>
>>>> Maybe what scares Walter is a whole new syntax for properties.
>>>
>>> It doesn't scare me. It's trivial to add more syntax.
>>>
>>> It's just that D is complex enough - there needs to be some very good
>>> reasons for adding more syntax that has apparently zero semantic information
>>> that would be different from the usual function syntax.
>>
>> OK, so you don't like the idea of adding dedicated properties.
>>
>> What is *your* solution to forbidding abuses like this:
>>
>> writefln = "hi";
>>
>> ???
>>
>
> I think his suggestion was the Java-style approach -- special naming
> convention for get/set functions:
>
> int opGet_foo() { return foo_; }
> void opSet_foo(int foo) { foo_ = foo; }
> private:
> int foo_;
Really? I got the impression that he does not think properties warrant any kind of special syntax.
If that's the solution it's ok with me, the only issue is name collision (as others have mentioned):
int opGet_foo()
int foo;
must be forbidden. This is different from other opX operators since the true names of those operators cannot be symbols, and therefore could never have collisions.
-Steve
|
July 27, 2009 Re: Reddit: why aren't people using D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | Bill Baxter wrote:
> On Mon, Jul 27, 2009 at 7:13 AM, Steven
> Schveighoffer<schveiguy@yahoo.com> wrote:
>> On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>
>>> Ary Borenszweig wrote:
>>>> Maybe what scares Walter is a whole new syntax for properties.
>>> It doesn't scare me. It's trivial to add more syntax.
>>>
>>> It's just that D is complex enough - there needs to be some very good
>>> reasons for adding more syntax that has apparently zero semantic information
>>> that would be different from the usual function syntax.
>> OK, so you don't like the idea of adding dedicated properties.
>>
>> What is *your* solution to forbidding abuses like this:
>>
>> writefln = "hi";
>>
>> ???
>>
>
> I think his suggestion was the Java-style approach -- special naming
> convention for get/set functions:
>
> int opGet_foo() { return foo_; }
> void opSet_foo(int foo) { foo_ = foo; }
> private:
> int foo_;
>
> --bb
For one thing I like that I now get to define empty() for a range and then call it with r.empty. I'd think it would be a small step backward if I had to define get_empty() or something instead.
Andrei
|
July 27, 2009 Re: Reddit: why aren't people using D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sergey Gromov | Sergey Gromov wrote: > The only thing copy-construction is useful for is implementing move semantics, think std::auto_ptr. Seems like everything else can be done in post-blit. The "linked list" implementation of smart pointers also requires a copy constructor. It's (arguably) not a very good design, but it is a valid design. > The inability to overload opAssign(typeof(this)) is a blocker for robust > RAII though. Yes. -- Rainer Deyke - rainerd@eldwood.com |
July 27, 2009 Re: Reddit: why aren't people using D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Mon, 27 Jul 2009 13:59:53 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote: > Bill Baxter wrote: >> On Mon, Jul 27, 2009 at 7:13 AM, Steven >> Schveighoffer<schveiguy@yahoo.com> wrote: >>> On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright >>> <newshound1@digitalmars.com> wrote: >>> >>>> Ary Borenszweig wrote: >>>>> Maybe what scares Walter is a whole new syntax for properties. >>>> It doesn't scare me. It's trivial to add more syntax. >>>> >>>> It's just that D is complex enough - there needs to be some very good >>>> reasons for adding more syntax that has apparently zero semantic information >>>> that would be different from the usual function syntax. >>> OK, so you don't like the idea of adding dedicated properties. >>> >>> What is *your* solution to forbidding abuses like this: >>> >>> writefln = "hi"; >>> >>> ??? >>> >> I think his suggestion was the Java-style approach -- special naming >> convention for get/set functions: >> int opGet_foo() { return foo_; } >> void opSet_foo(int foo) { foo_ = foo; } >> private: >> int foo_; >> --bb > > For one thing I like that I now get to define empty() for a range and then call it with r.empty. I'd think it would be a small step backward if I had to define get_empty() or something instead. The "getter" notation that currently exists only has a few minor problems. The most major of those problems is if the return value is a callable type, such as a delegate, you can't easily perform the call on the returned value. Being that it isn't very bad for the getter property, would it make sense to leave that functionality? That is: 1. A setter must be defined in the opSet_X(int x) form 2. A getter can be a function with no required arguments, but this getter should not return callable types 3. A getter can be defined in the opGet_X() form, and then using X() will be the eqivalent of opGet_X()(). There are small implications to leaving the existing getter syntax. Namely one can call a function not intended to be a getter in a property-like syntax, resulting in less-than-obvious code. Also, this distinction will be very hard to explain to newbies ("how come a getter is defined as x(), but a setter has to be opSet_x(...)?). The more I look at it, the more I like the keyword solution. I do find the C#-like syntax which groups properties together appealing, but I think you only absolutely need that if you are going to have context-keywords, which I DON'T think we need. I do find the whole construct of C# properties tedious to type. With a keyword attribute, you could even group your properties together to save on typing/ugliness: property { int x() {} void x(int n) {} bool empty() {} } -Steve |
July 27, 2009 Re: Reddit: why aren't people using D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | Steven Schveighoffer:
> property
> {
> int x() {}
> void x(int n) {}
> bool empty() {}
> }
An alternative:
property(x) {
... // or getter and/or setter
}
Bye,
bearophile
|
Copyright © 1999-2021 by the D Language Foundation