Alexander Pánek:
> Guripe. Gripe gripe. GRIPE.
Is this the second (redundant) system to vote for the most hated bugs?
Bye,
bearophile
bearophile wrote:
Alexander Pánek:
Guripe. Gripe gripe. GRIPE.
Is this the second (redundant) system to vote for the most hated bugs?
Bye,
bearophile
Maybe we need a bot to monitor bugs' GPS [1]. You can never have too
many redundant systems, afterall!
-- Daniel
P.S. Gripe gripe
"Walter Bright" kirjoitti viestissä
news:gk1dag$pt...@digitalmars.com...
I keep thinking I should put on a "Compiler Construction" seminar!
A net-seminar, please, so that those of us who want to attend actually can.
Andrei Alexandrescu wrote:
Don wrote:
Denis Koroskin wrote:
On Thu, 18 Dec 2008 01:38:32 +0300, Sergey Gromov
Thu, 18 Dec 2008 00:21:58 +0300, Denis Koroskin wrote:
On Thu, 18 Dec 2008 00:12:18 +0300, Sergey Gromov
Tue, 16 Dec 2008 10:09:41 +0100, Don wrote:
struct Foo { double, int } // 12
dsimcha wrote:
> Yeah, this has been mentioned in the past before. The most obvious way to
> make it work w/o any breaking or significantly bulk-adding changes would
> be to define foo.length += 8 to mean foo = foo.length() + 8, or
> foo.length++ mean foo =
> foo.length + 1. This would be pure s
Hello all,
I want to suggest adding module opCall to D (to D1 as well please :). Please
excuse me if has been suggested before. Something like this:
module mymodule.trace;
static char[] opCall() {
return "whatever";
}
module mymodule.main;
void main() {
mymodule.trace();
}
The need for
Gripe, Gripe, Gripe. Gripe, Gripe, Gripe, Wonderful Gripe...
dsimcha wrote:
== Quote from BCS (a...@pathlink.com)'s article
Reply to Vishaal,
Properties, such as array.length, should return lvalues to allow:
a.length += 8;
or other similar statements.
I think there is a (long standing) bug report about that one. Maybe if enough
people gripe about it it
"Michiel Helvensteijn" wrote in message
news:gk4oi2$14t...@digitalmars.com...
> dsimcha wrote:
>
>> Yeah, this has been mentioned in the past before. The most obvious way
>> to
>> make it work w/o any breaking or significantly bulk-adding changes would
>> be to define foo.length += 8 to mean fo
"Rioshin an'Harthen" wrote in message
news:gk4kfh$ri...@digitalmars.com...
> "Walter Bright" kirjoitti viestissä
> news:gk1dag$pt...@digitalmars.com...
>> I keep thinking I should put on a "Compiler Construction" seminar!
>
> A net-seminar, please, so that those of us who want to attend actuall
Nick Sabalausky wrote:
> 1. Like in C#, you shouldn't need to define paramater lists for "set" and
> "get". They're always going to be the same. In the case of "set", it's
> always going to be just the one param, and it'll be the new value, so just
> make a special predefined var. Something like:
Michiel Helvensteijn wrote:
Nick Sabalausky wrote:
1. Like in C#, you shouldn't need to define paramater lists for "set" and
"get". They're always going to be the same. In the case of "set", it's
always going to be just the one param, and it'll be the new value, so just
make a special predefine
Ary Borenszweig wrote:
>>> get { return this.len; }
>>> set { this.len = value; } // "value" (like in C#), or "$" or something
>>> like that
>>
>> I have to disagree. By that logic, we would abolish parameter-names
>> altogether and access formal parameters by number. set has a parameter,
>> and
bobef Wrote:
> The need for this is because often a module happens to be named as the
> functionality it contains and you have to write the stuff two times.<
A design bug in the D1 module system is that when you import foo normally you
import in the namespace both the module name and the names i
Michiel Helvensteijn wrote:
Ary Borenszweig wrote:
get { return this.len; }
set { this.len = value; } // "value" (like in C#), or "$" or something
like that
I have to disagree. By that logic, we would abolish parameter-names
altogether and access formal parameters by number. set has a paramete
Ary Borenszweig wrote:
>>> It's very different. A setter has a very specific meaning: set some
>>> value. That's why it's called "value". Another name could be the name of
>>> the property ("len") or something like "newLen". Which other name would
>>> you use?
>>
>> It's not for me to say. It sho
Michiel Helvensteijn wrote:
> Nick Sabalausky wrote:
>
>> 2. You shouldn't have to manually define a private var to go along with
>> the property. In languages with real properties, the following idiom is
>> used constantly:
>>
>> private int _var;
>> public property int var {
>>get { return _
"Michiel Helvensteijn" wrote in message
news:gk5b4m$2ek...@digitalmars.com...
> Nick Sabalausky wrote:
>
>> 1. Like in C#, you shouldn't need to define paramater lists for "set" and
>> "get". They're always going to be the same. In the case of "set", it's
>> always going to be just the one param,
"Michiel Helvensteijn" wrote in message
news:gk5f80$2la...@digitalmars.com...
> Ary Borenszweig wrote:
>
It's very different. A setter has a very specific meaning: set some
value. That's why it's called "value". Another name could be the name
of
the property ("len") or someth
Chad J:
> public property int var
> {
> get { return var; }
> set { var = $; }
> }
>
> public property int foo
> {
> get { return foo; }
> set { foo = $; }
> }
I think I have suggested something similar, time ago.
The default situations you have shown may enjoy an even shorter sy
Reply to Walter,
Robert Fraser wrote:
Walter Bright wrote:
I keep thinking I should put on a "Compiler Construction" seminar!
*cough* NWCPP *cough*
I'd like to do a paid one .
BTW, Bartosz has graciously offered the Jan NWCPP speaking engagement
to me. I'll be talking about mixins and t
"Chad J" wrote in message
news:gk5fch$2ld...@digitalmars.com...
> Michiel Helvensteijn wrote:
>> Nick Sabalausky wrote:
>>
>>> 2. You shouldn't have to manually define a private var to go along with
>>> the property. In languages with real properties, the following idiom is
>>> used constantly:
>
Nick Sabalausky wrote:
>> Perhaps the implicit declaration "value" (or whatever *you* would call
>> it) inadvertently overshadows a member variable with that name. That
>> could result in a bug that would be pretty hard to find.
>>
>
> Overshadowing is already a potential issue anyway, with or wi
"Nick Sabalausky" wrote in message
news:gk5fo7$2m8...@digitalmars.com...
> "Michiel Helvensteijn" wrote in message
> news:gk5b4m$2ek...@digitalmars.com...
>> Nick Sabalausky wrote:
>>
>>> 1. Like in C#, you shouldn't need to define paramater lists for "set"
>>> and
>>> "get". They're always go
"bearophile" wrote in message
news:gk5grh$2o8...@digitalmars.com...
> Chad J:
>> public property int var
>> {
>> get { return var; }
>> set { var = $; }
>> }
>>
>> public property int foo
>> {
>> get { return foo; }
>> set { foo = $; }
>> }
>
> I think I have suggested something s
On Fri, Jan 9, 2009 at 2:33 AM, bearophile wrote:
> bobef Wrote:
>> The need for this is because often a module happens to be named as the
>> functionality it contains and you have to write the stuff two times.<
>
> A design bug in the D1 module system is that when you import foo normally you
>
"Michiel Helvensteijn" wrote in message
news:gk5h9r$2p7...@digitalmars.com...
> Nick Sabalausky wrote:
>
>>> Perhaps the implicit declaration "value" (or whatever *you* would call
>>> it) inadvertently overshadows a member variable with that name. That
>>> could result in a bug that would be pret
Walter Bright Wrote:
> Nick Sabalausky wrote:
> > I guess there was confusion about DMD support for a particular host
> > platform
> > vs a particular target platform. If DMD does't even run or work correctly
> > on
> > 64-bit machines, even in 32-bit mode, (I don't know, as I don't use them)
Walter Bright Wrote:
> Nick Sabalausky wrote:
> > I guess there was confusion about DMD support for a particular host
> > platform
> > vs a particular target platform. If DMD does't even run or work correctly
> > on
> > 64-bit machines, even in 32-bit mode, (I don't know, as I don't use them)
Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Denis Koroskin wrote:
On Thu, 18 Dec 2008 01:38:32 +0300, Sergey Gromov
Thu, 18 Dec 2008 00:21:58 +0300, Denis Koroskin wrote:
On Thu, 18 Dec 2008 00:12:18 +0300, Sergey Gromov
Tue, 16 Dec 2008 10:09:41 +0100, Don wrote:
struct Foo { double,
Nick Sabalausky wrote:
> It's a DRY violation.
I agree, good call.
Nick Sabalausky wrote:
"bearophile" wrote in message
news:gk5grh$2o8...@digitalmars.com...
Chad J:
public property int var
{
get { return var; }
set { var = $; }
}
public property int foo
{
get { return foo; }
set { foo = $; }
}
I think I have suggested something similar,
"Yigal Chripun" wrote in message
news:gk5t92$fu...@digitalmars.com...
> Nick Sabalausky wrote:
>> "bearophile" wrote in message
>> news:gk5grh$2o8...@digitalmars.com...
>>> Chad J:
public property int var
{
get { return var; }
set { var = $; }
}
publi
Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Denis Koroskin wrote:
On Thu, 18 Dec 2008 01:38:32 +0300, Sergey Gromov
Thu, 18 Dec 2008 00:21:58 +0300, Denis Koroskin wrote:
On Thu, 18 Dec 2008 00:12:18 +0300, Sergey Gromov
Tue, 16 Dec 2008 10:09:41 +0100, Don wrote:
struct Foo { double,
BCS wrote:
Reply to Walter,
Robert Fraser wrote:
Walter Bright wrote:
I keep thinking I should put on a "Compiler Construction" seminar!
*cough* NWCPP *cough*
I'd like to do a paid one .
BTW, Bartosz has graciously offered the Jan NWCPP speaking engagement
to me. I'll be talking about
Nick Sabalausky wrote:
"Rioshin an'Harthen" wrote in message
news:gk4kfh$ri...@digitalmars.com...
"Walter Bright" kirjoitti viestissä
news:gk1dag$pt...@digitalmars.com...
I keep thinking I should put on a "Compiler Construction" seminar!
A net-seminar, please, so that those of us who want to
Nick Sabalausky wrote:
> A property setter is ALWAYS going to return nothing and
Both the getter and the setter should return an rvalue. Properties exist
so that they are interchangeable with real member variables. Something
that is possible with member variables MUST also be possible with
propert
Bill Baxter:
>I think this problem you refer to only applies to modules without package
>names. I.e. "module Foo" containing "class Foo". Things seem to work ok if
>you have "module x.Foo" with "class Foo" inside.<
Right. But why settle with a half-backed module system when there are more
lo
Chad J wrote:
> I actually like the idea.
>
> (...)
>
> int nTimesVarRead = 0;
>
> public property int var
> {
> get
> {
> nTimesVarRead++;
> return internalValue;
> }
>
> set { internalValue = $; }
> }
That defeats one of the purposes of properties. A property
On Fri, Jan 9, 2009 at 9:59 AM, Miles <...@___.> wrote:
> Nick Sabalausky wrote:
>> A property setter is ALWAYS going to return nothing and
>
> Both the getter and the setter should return an rvalue. Properties exist
> so that they are interchangeable with real member variables.
Partly
On Fri, Jan 9, 2009 at 10:23 AM, bearophile wrote:
> Bill Baxter:
>
>>I think this problem you refer to only applies to modules without package
>>names. I.e. "module Foo" containing "class Foo". Things seem to work ok if
>>you have "module x.Foo" with "class Foo" inside.<
>
> Right. But why se
"Miles" <...@___.> wrote in message
news:gk67hr$17d...@digitalmars.com...
> Nick Sabalausky wrote:
>> A property setter is ALWAYS going to return nothing and
>
> Both the getter and the setter should return an rvalue. Properties exist
> so that they are interchangeable with real member
"Bill Baxter" wrote in message
news:mailman.343.1231465331.22690.digitalmar...@puremagic.com...
> On Fri, Jan 9, 2009 at 9:59 AM, Miles <...@___.> wrote:
>> Nick Sabalausky wrote:
>>> A property setter is ALWAYS going to return nothing and
>>
>> Both the getter and the setter should r
On Fri, Jan 9, 2009 at 10:58 AM, Nick Sabalausky wrote:
> "Bill Baxter" wrote in message
> news:mailman.343.1231465331.22690.digitalmar...@puremagic.com...
>> On Fri, Jan 9, 2009 at 9:59 AM, Miles <...@___.> wrote:
>>> Nick Sabalausky wrote:
A property setter is ALWAYS going to r
Bill Baxter wrote:
> On Fri, Jan 9, 2009 at 9:59 AM, Miles <...@___.> wrote:
>> Both the getter and the setter should return an rvalue. Properties exist
>> so that they are interchangeable with real member variables.
>
> Partly, but also properties exist to provide encapsulation of pri
On Fri, Jan 9, 2009 at 11:01 AM, Miles <...@___.> wrote:
> Bill Baxter wrote:
>> On Fri, Jan 9, 2009 at 9:59 AM, Miles <...@___.> wrote:
>>> Both the getter and the setter should return an rvalue. Properties exist
>>> so that they are interchangeable with real member variabl
Another thread just reminded me of something I use frequently in C++
that doesn't work in D because ++x is not an lvalue:
int x,N;
...
++x %= N;
So is there some deep reason for not making it an lvalue like in C++?
--bb
Nick Sabalausky wrote:
> True, but my main point was, however the language ends up handling the
> details of property getters/setters, it's not going to be as general as
> ordinary functions, and thus certain aspects of the syntax can/should be
> simplified.
In this case, simplifying would be m
"Miles" <...@___.> wrote in message
news:gk68q1$19g...@digitalmars.com...
> Chad J wrote:
>> I actually like the idea.
>>
>> (...)
>>
>> int nTimesVarRead = 0;
>>
>> public property int var
>> {
>> get
>> {
>> nTimesVarRead++;
>> return internalValue;
>> }
>
"Miles" <...@___.> wrote in message
news:gk6f9p$1jv...@digitalmars.com...
> Nick Sabalausky wrote:
>> True, but my main point was, however the language ends up handling the
>> details of property getters/setters, it's not going to be as general as
>> ordinary functions, and thus certai
Bill Baxter пишет:
> Another thread just reminded me of something I use frequently in C++
> that doesn't work in D because ++x is not an lvalue:
>
>int x,N;
> ...
>++x %= N;
>
> So is there some deep reason for not making it an lvalue like in C++?
>
++x is x+=1 in D:
void main() {
- Original Message -
From: "Bill Baxter"
Newsgroups: digitalmars.D
To: "digitalmars.D"
Sent: Thursday, January 08, 2009 8:49 PM
Subject: Re: Suggestion: module opcall
> On Fri, Jan 9, 2009 at 10:23 AM, bearophile
> wrote:
>> Bill Baxter:
>>
>>>I think this problem you refer to only ap
"Walter Bright" wrote in message
news:gk6150$n6...@digitalmars.com...
> Nick Sabalausky wrote:
>> "Rioshin an'Harthen" wrote in message
>> news:gk4kfh$ri...@digitalmars.com...
>>> "Walter Bright" kirjoitti viestissä
>>> news:gk1dag$pt...@digitalmars.com...
I keep thinking I should put on
2009/1/9 Weed :
> Bill Baxter пишет:
>> Another thread just reminded me of something I use frequently in C++
>> that doesn't work in D because ++x is not an lvalue:
>>
>>int x,N;
>> ...
>>++x %= N;
>>
>> So is there some deep reason for not making it an lvalue like in C++?
>>
>
> ++x is x
Bill Baxter пишет:
> 2009/1/9 Weed :
>> Bill Baxter пишет:
>>> Another thread just reminded me of something I use frequently in C++
>>> that doesn't work in D because ++x is not an lvalue:
>>>
>>>int x,N;
>>> ...
>>>++x %= N;
>>>
>>> So is there some deep reason for not making it an lvalu
On Fri, Jan 9, 2009 at 2:22 PM, Weed wrote:
> Bill Baxter пишет:
>> 2009/1/9 Weed :
>>> Bill Baxter пишет:
Another thread just reminded me of something I use frequently in C++
that doesn't work in D because ++x is not an lvalue:
int x,N;
...
++x %= N;
>>>
Weed пишет:
> Bill Baxter пишет:
>> 2009/1/9 Weed :
>>> Bill Baxter пишет:
Another thread just reminded me of something I use frequently in C++
that doesn't work in D because ++x is not an lvalue:
int x,N;
...
++x %= N;
So is there some deep reason fo
On Fri, Jan 9, 2009 at 2:43 PM, Weed wrote:
> Weed пишет:
>> Bill Baxter пишет:
>>> 2009/1/9 Weed :
Bill Baxter пишет:
> Another thread just reminded me of something I use frequently in C++
> that doesn't work in D because ++x is not an lvalue:
>
>int x,N;
> ...
Miles wrote:
>
> Both the getter and the setter should return an rvalue. Properties exist
> so that they are interchangeable with real member variables. Something
> that is possible with member variables MUST also be possible with
> properties, in a transparent way for any code outside the class.
"Weed" wrote in message
news:gk6n29$218...@digitalmars.com...
> Bill Baxter ?:
>> 2009/1/9 Weed :
>>> Bill Baxter ?:
Another thread just reminded me of something I use frequently in C++
that doesn't work in D because ++x is not an lvalue:
int x,N;
...
Bill Baxter пишет:
> On Fri, Jan 9, 2009 at 2:22 PM, Weed wrote:
>> Bill Baxter пишет:
>>> 2009/1/9 Weed :
Bill Baxter пишет:
> Another thread just reminded me of something I use frequently in C++
> that doesn't work in D because ++x is not an lvalue:
>
>int x,N;
> .
Nick Sabalausky пишет:
> "Weed" wrote in message
> news:gk6n29$218...@digitalmars.com...
>> Bill Baxter ?:
>>> 2009/1/9 Weed :
Bill Baxter ?:
> Another thread just reminded me of something I use frequently in C++
> that doesn't work in D because ++x is not an lvalue:
>
>>
Bill Baxter пишет:
> On Fri, Jan 9, 2009 at 2:43 PM, Weed wrote:
>> Weed пишет:
>>> Bill Baxter пишет:
2009/1/9 Weed :
> Bill Baxter пишет:
>> Another thread just reminded me of something I use frequently in C++
>> that doesn't work in D because ++x is not an lvalue:
>>
>>
63 matches
Mail list logo
