On 3/2/2011 9:21 PM, Jonathan M Davis wrote:
Well, it wouldn't be universal then.
Agreed, and really, I don't have a problem with it being universal. I'd
prefer an annotation, but it's not that big a deal. I'm just thinking
of the following situation:
lib1.di:
class Lib1Class
On Wednesday 02 March 2011 23:12:43 %u wrote:
> > Well, it wouldn't be universal then. For a function to be treated
>
> as a property, it would require an annotation, but universal
> function call syntax isn't supposed to require an annotation any
> more than calling a function on an array as if i
> Well, it wouldn't be universal then. For a function to be treated
as a property, it would require an annotation, but universal
function call syntax isn't supposed to require an annotation any
more than calling a function on an array as if it were a member
function requires an annotation. It's sup
I use GtkD for my yet-to-be-released personal project. I recently
submitted a GtkD bug report recently and it didn't go anywhere, so I
hand-patched the generated code locally.
I also maintain my own patch to allow it to build with the latest
version of dmd-2 with warnings enabled.
On the who
On Wednesday 02 March 2011 21:09:09 Bekenn wrote:
> On 3/2/2011 8:41 PM, Jonathan M Davis wrote:
> > Uniform Function Call Syntax. It means that _any_ type could have
> > functions called on it as if they were member functions of that type.
> > e.g.
>
> OK, thanks.
>
> This sounds like the sort o
I've been using GtkD for my Plot2kill plotting library, and overall it
appears to be the most mature D GUI library available. However, I've
noticed that no commits have taken place for several months, and nobody
seems to want to test the 64-bit support patch I submitted.
Is the lack of GtkD a
On 3/2/2011 8:41 PM, Jonathan M Davis wrote:
Uniform Function Call Syntax. It means that _any_ type could have functions
called on it as if they were member functions of that type. e.g.
OK, thanks.
This sounds like the sort of thing that should require an annotation in
the declaration...
"dsimcha" wrote in message
news:ikmgbu$2fmc$1...@digitalmars.com...
>
> First of all, I thought that we had decided that DMD's enforcement of
> @property
> would be loose, i.e. it should only be used to disambiguate in cases where
> ambiguity exists (for example, when returning delegates). As l
On Wednesday 02 March 2011 20:17:48 Bekenn wrote:
> On 3/2/2011 6:36 PM, Jonathan M Davis wrote:
> > Because a property must be a property _of_ something. It's essentially an
> > abstraction of a member variable. It allows you to use a function as if
> > it were a member variable. That's its whole
On 3/2/2011 6:36 PM, Jonathan M Davis wrote:
Because a property must be a property _of_ something. It's essentially an
abstraction of a member variable. It allows you to use a function as if it were
a member variable. That's its whole purpose.
Very much agreed.
I'm not sure I'm familiar with U
On Wednesday 02 March 2011 18:02:18 Michel Fortin wrote:
> On 2011-03-02 20:56:41 -0500, Jonathan M Davis said:
> > I would argue that properties make no sense unless they have a "this"
> > parameter to work.
>
> I would argue that properties make sense everywhere variables make
> sense. Why shou
On 2011-03-02 20:56:41 -0500, Jonathan M Davis said:
I would argue that properties make no sense unless they have a "this" parameter
to work.
I would argue that properties make sense everywhere variables make
sense. Why should they be restricted to classes and structs?
--
Michel Fortin
mic
On Wednesday, March 02, 2011 16:57:42 Michel Fortin wrote:
> On 2011-03-02 17:14:30 -0500, Jonathan M Davis said:
> > I would expect the compiler to be smart enough to combine the fact that
> > you can call functions on arrays as if they were member functions and
> > @property to allow
> > you to
Andrei:
> http://www.reddit.com/r/programming/comments/ftgok/types_considered_harmful/
It's an interesting slides pack, but it's not easy to follow for me, it assumes
some knowledge I don't have yet.
>From the slides:
>Fancy types make the programmer's head hurt<
Languages are used to solve m
Am 03.03.2011 02:22, schrieb Andrei Alexandrescu:
> On 3/2/11 7:09 PM, Daniel Gibson wrote:
>> What were the reasons for not listing D anyway?
>
> I suggest we stop this discussion right here as there's no chance it doesn't
> turn political. It has occurred a couple of times in the past, with the
On 3/2/11 7:09 PM, Daniel Gibson wrote:
What were the reasons for not listing D anyway?
I suggest we stop this discussion right here as there's no chance it
doesn't turn political. It has occurred a couple of times in the past,
with the effect that people wrote email to Isaac asking him the q
Am 03.03.2011 02:01, schrieb Andrei Alexandrescu:
> On 3/2/11 6:38 PM, bearophile wrote:
>> Andrei:
>>
>>> my understanding is that Isaac has nothing against D but
>>> can't be bothered with a 32-bit setup. Perhaps now with the 64-bit
>>> edition maturing, we can look forward to seeing dmd reinclud
On 3/2/11 6:38 PM, bearophile wrote:
Andrei:
my understanding is that Isaac has nothing against D but
can't be bothered with a 32-bit setup. Perhaps now with the 64-bit
edition maturing, we can look forward to seeing dmd reincluded. Of
course, if the benchmarks are already set up properly and w
On 2011-03-02 17:29:18 -0500, dsimcha said:
First of all, I thought that we had decided that DMD's enforcement of @property
would be loose, i.e. it should only be used to disambiguate in cases where
ambiguity exists (for example, when returning delegates). As long as
there's no
ambiguity, @p
On 2011-03-02 17:14:30 -0500, Jonathan M Davis said:
I would expect the compiler to be smart enough to combine the fact that you can
call functions on arrays as if they were member functions and @property
to allow
you to deal with any property as if it were a member of the array. So, the fact
Andrei:
> my understanding is that Isaac has nothing against D but
> can't be bothered with a 32-bit setup. Perhaps now with the 64-bit
> edition maturing, we can look forward to seeing dmd reincluded. Of
> course, if the benchmarks are already set up properly and working, he'll
> be much easi
On 3/2/11 5:41 PM, Jason E. Aten wrote:
What pisses me off is the Issac Guy doesn't want to support D in the
great language benchmark. It's very important utlity for developers.
Most coders with C and C++ mentality look the charts and only use
the top-2 languages, that is C and C
> What pisses me off is the Issac Guy doesn't want to support D in the great
> language benchmark. It's very important utlity for developers. Most coders
> with C and C++ mentality look the charts and only use the top-2 languages,
> that is C and C++. If D was there, we could get more users right n
Andrei Alexandrescu Wrote:
> On 3/2/11 3:20 PM, Walter Bright wrote:
> > dsimcha wrote:
> >> == Quote from Walter Bright (newshou...@digitalmars.com)'s article
> >>> bearophile wrote:
> Bekenn:
>
> > The use of ref introduces a level of indirection.
> This is correct. But a mini
On 3/2/11 3:20 PM, Walter Bright wrote:
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
bearophile wrote:
Bekenn:
The use of ref introduces a level of indirection.
This is correct. But a minimally decent compiler must be able to
remove this
indirection wher
== Quote from Michel Fortin (michel.for...@michelf.com)'s article
> Consider that currently, using an array as a range is implemented this way:
> int front(int[] array) {
> return array[0];
> }
> int[] array = [1,2,3];
> auto e = array.front;
> Currently, this
On Wednesday, March 02, 2011 13:49:40 Michel Fortin wrote:
> Consider that currently, using an array as a range is implemented this way:
>
> int front(int[] array) {
> return array[0];
> }
>
> int[] array = [1,2,3];
> auto e = array.front;
>
> Currently, thi
Consider that currently, using an array as a range is implemented this way:
int front(int[] array) {
return array[0];
}
int[] array = [1,2,3];
auto e = array.front;
Currently, this work fine because the compiler treats "array.front" and
"array.fr
"Kagamin" wrote in message
news:iklanl$1qg$1...@digitalmars.com...
> Nick Sabalausky Wrote:
>
>> Name one case in windows where some sort of distinction between filename
>> and
>> extension actually makes a real tangible difference versus unix, that
>> doesn't merely amount to convention
>
> You
"Kagamin" wrote in message
news:ikl9vq$b0$1...@digitalmars.com...
> Bekenn Wrote:
>
>> On 3/1/11 3:27 PM, Walter Bright wrote:
>> > I've always hated the Windows "Documents and Settings" subdirectory.
>> > Arggh. Always a pain to use on the command line.
>>
>> No kidding. Thank goodness that's g
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
bearophile wrote:
Bekenn:
The use of ref introduces a level of indirection.
This is correct. But a minimally decent compiler must be able to remove this
indirection where possible, like here, and produce effici
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> bearophile wrote:
> > Bekenn:
> >
> >> The use of ref introduces a level of indirection.
> >
> > This is correct. But a minimally decent compiler must be able to remove this
> > indirection where possible, like here, and produce e
bearophile wrote:
Bekenn:
The use of ref introduces a level of indirection.
This is correct. But a minimally decent compiler must be able to remove this
indirection where possible, like here, and produce efficient code.
Having the optimizer remove indirection is rarely possible in C or C++,
The use of ref introduces a level of indirection. I suspect the writer
was trying to avoid copying array elements -- unnecessary, since
vector_t was defined as a dynamic array, where only the bounds are
passed.
Yeah I overlooked that, I always think of a struct when thinking about
vector
Bekenn:
> The use of ref introduces a level of indirection.
This is correct. But a minimally decent compiler must be able to remove this
indirection where possible, like here, and produce efficient code.
Bye,
bearophile
On 3/2/11 11:40 AM, Trass3r wrote:
I just can't imagine why in should be faster than const ref.
The use of ref introduces a level of indirection. I suspect the writer
was trying to avoid copying array elements -- unnecessary, since
vector_t was defined as a dynamic array, where only the boun
(such as in being faster than const ref - I would have guessed the
opposite):
I just can't imagine why in should be faster than const ref.
On Wed, 02 Mar 2011 13:38:05 -0500, Bekenn wrote:
On 3/2/11 8:45 AM, spir wrote:
I had never thought at that, but I'm surprised: what prevents Python's
"compiler" (say, a semantic phase after parsing) to check number and
names of arguments. (Number seems not to be checked before runtime
neithe
On 3/2/11 8:45 AM, spir wrote:
I had never thought at that, but I'm surprised: what prevents Python's
"compiler" (say, a semantic phase after parsing) to check number and
names of arguments. (Number seems not to be checked before runtime
neither.)
All required information is in the AST. For named
I just thought that I'd point out this question on stackoverflow for those of
you
who don't regularly frequent stackoverflow. It has some fairly interesting info
(such as in being faster than const ref - I would have guessed the opposite):
http://stackoverflow.com/questions/5142366/how-fast-is-
On 01/03/2011 11:59, spir wrote:
On the other hand, I would like it still be possible to write:
void f (x=0, y=0) {...}
...
f(y=1);
It would. And it would still set the variable y in the calling scope to 1, and then call
f(1, 0).
Stewart.
On 3/2/11 8:45 AM, Jim wrote:
In addition to that, named template arguments would allow you to
create very customizable, yet lean types. It would be possible to
parameterize all components. Basically, if you're not pleased with
the default search algorithm or container type of a more complex
obje
On 03/02/2011 02:59 PM, Steven Schveighoffer wrote:
On Wed, 02 Mar 2011 08:45:43 -0500, Jason E. Aten wrote:
I find this an interesting discussion. Coming from writing alot of code in
language that makes extensive and
highly effective use of named arguments (R), I can say that optional named
a
On Wed, 02 Mar 2011 10:06:17 -0500, Jason E. Aten
wrote:
On Wed, Mar 2, 2011 at 8:45 AM, Jim wrote:
In addition to that, named template arguments would allow you to create
very customizable, yet lean types. It would be possible to parameterize
all
components. Basically, if you're not pl
On Wed, Mar 2, 2011 at 8:45 AM, Jim wrote:
>
> In addition to that, named template arguments would allow you to create
> very customizable, yet lean types. It would be possible to parameterize all
> components. Basically, if you're not pleased with the default search
> algorithm or container type
Steven Schveighoffer Wrote:
> On Wed, 02 Mar 2011 08:45:43 -0500, Jason E. Aten
> wrote:
>
> > I find this an interesting discussion. Coming from writing alot of code
> > in
> > language that makes extensive and
> > highly effective use of named arguments (R), I can say that optional
> >
On Wed, 02 Mar 2011 08:45:43 -0500, Jason E. Aten
wrote:
I find this an interesting discussion. Coming from writing alot of code
in
language that makes extensive and
highly effective use of named arguments (R), I can say that optional
named
arguments
(as in Lisp, and descendants like Py
I find this an interesting discussion. Coming from writing alot of code in
language that makes extensive and
highly effective use of named arguments (R), I can say that optional named
arguments
(as in Lisp, and descendants like Python and R) do have big software
engineering benefits,
but also come
Jim wrote:
Jonathan M Davis Wrote:
On Tuesday, March 01, 2011 11:22:17 Bekenn wrote:
On 2/28/11 1:38 PM, Don wrote:
1. It makes parameter names part of the API.
I wrote earlier that this would probably be the first time parameter
names "leaked" into user code, but I was wrong. Jacob Carlbor
Nick Sabalausky Wrote:
> Name one case in windows where some sort of distinction between filename and
> extension actually makes a real tangible difference versus unix, that
> doesn't merely amount to convention
You can pass program path to CreateProcess without extension, .exe is assumed.
Bekenn Wrote:
> On 3/1/11 3:27 PM, Walter Bright wrote:
> > I've always hated the Windows "Documents and Settings" subdirectory.
> > Arggh. Always a pain to use on the command line.
>
> No kidding. Thank goodness that's gone post-XP. Now if only they'd do
> the same for Program Files...
Did b
"Lars T. Kyllingstad" wrote in message
news:ikl3m2$2i6s$1...@digitalmars.com...
> On Tue, 01 Mar 2011 20:45:15 -0500, Nick Sabalausky wrote:
>
>> "Lars T. Kyllingstad" wrote in message
>> news:ikiht0$2vba$2...@digitalmars.com...
>>>
>>> I've also found a few cases like that. In general, I think
On 3/2/2011 1:34 AM, Max Samukha wrote:
I am not against named arguments. What I wanted to say is that
writef(formatstr: "...", ) does not make the code more readable.
Right, agreed. This is one of the "not helpful" cases, where you simply
don't use named arguments. I'd expect (and hope for)
Jonathan M Davis Wrote:
> On Tuesday, March 01, 2011 11:22:17 Bekenn wrote:
> > On 2/28/11 1:38 PM, Don wrote:
> > > 1. It makes parameter names part of the API.
> >
> > I wrote earlier that this would probably be the first time parameter
> > names "leaked" into user code, but I was wrong. Jacob
On Tue, 01 Mar 2011 20:45:15 -0500, Nick Sabalausky wrote:
> "Lars T. Kyllingstad" wrote in message
> news:ikiht0$2vba$2...@digitalmars.com...
>>
>> I've also found a few cases like that. In general, I think std.path
>> takes the KISS approach, probably because it's the most efficient and
>> wor
On 01.03.2011 20:55, Bekenn wrote:
On 3/1/11 4:52 AM, Max Samukha wrote:
I hate that "explicitness improves code clarity and readability"
argument. It may be true in some cases but most of the time explicitness
creates unnecessary redundancy that actually impairs readability.
Correct. However,
56 matches
Mail list logo
