On Fri, 25 Sep 2009 00:07:08 -0400, Jeremie Pelletier
wrote:
Robert Jacques wrote:
On Thu, 24 Sep 2009 20:59:23 -0400, Jeremie Pelletier
wrote:
Robert Jacques wrote:
On Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier
wrote:
[snip]
Its the same for concurrency, I can think of vect
Rainer Deyke wrote:
> Lionello Lunesu wrote:
>> Be careful with that reasoning. What about attributes? Properties? What
>> about C# "var" vs. D "auto"? C# "using" vs. D "import"? In fact, what
>> about the standard library?
>
> I wouldn't wind at all if D copied more from C#, and I don't even like
Andrei Alexandrescu wrote:
> Lionello Lunesu wrote:
>> Andrei Alexandrescu wrote:
>>> Max Samukha wrote:
On Thu, 24 Sep 2009 23:55:57 +0800, Lionello Lunesu
wrote:
> Daniel Keep wrote:
>> Why not go with what C# uses?
>>
>> class LotterySimulation : Lottery, Figure {
language_fan wrote:
> The cost of e.g. doubling computing power depends on the domain. If you
> are building desktop end user applications, they usually should scale
> from single core atoms to 8-core high-end enthusiastic game computers. So
> the cpu requirements shouldn't usually be too large.
Lionello Lunesu wrote:
> Be careful with that reasoning. What about attributes? Properties? What
> about C# "var" vs. D "auto"? C# "using" vs. D "import"? In fact, what
> about the standard library?
I wouldn't wind at all if D copied more from C#, and I don't even like
C#. A natively compiled C#
Aenigmatic wrote:
> Is typedef (in D) a C/C++ legacy or is the dear orphan now adopted as
> a first-class citizen in the US of D?
typedef in D is a new feature not found in C or C++.
The typedef from C/C++ has been renamed to alias and extended to
non-types in D.
--
Rainer Deyke - rain...@eldw
language_fan wrote:
Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier thusly wrote:
language_fan wrote:
Wed, 23 Sep 2009 10:43:53 -0400, Jeremie Pelletier thusly wrote:
You're right about concurrency being a different concept than
threading,
but I wouldn't give threading away for a pure c
Robert Jacques wrote:
On Thu, 24 Sep 2009 20:59:23 -0400, Jeremie Pelletier
wrote:
Robert Jacques wrote:
On Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier
wrote:
[snip]
Its the same for concurrency, I can think of vector processing,
functional calls, STM, message passing and shared me
Christopher Wright wrote:
Jeremie Pelletier wrote:
language_fan wrote:
Wed, 23 Sep 2009 10:43:53 -0400, Jeremie Pelletier thusly wrote:
You're right about concurrency being a different concept than
threading,
but I wouldn't give threading away for a pure concurrent model
either.
I believe
On Thu, 24 Sep 2009 20:59:23 -0400, Jeremie Pelletier
wrote:
Robert Jacques wrote:
On Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier
wrote:
[snip]
Its the same for concurrency, I can think of vector processing,
functional calls, STM, message passing and shared memory off the top
o
Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier thusly wrote:
> language_fan wrote:
>> Wed, 23 Sep 2009 10:43:53 -0400, Jeremie Pelletier thusly wrote:
>>
>>> You're right about concurrency being a different concept than
>>> threading,
>>> but I wouldn't give threading away for a pure concur
Thu, 24 Sep 2009 21:41:00 -0400, bearophile thusly wrote:
> language_fan:
>
>> [lot of stuff...]
>> Switching to Python is in one way a step in the wrong direction - you
>> lose something you already had for free - [lot of stuff...]
>
> I know several languages but I'm usually able to write corr
Jeremie Pelletier wrote:
language_fan wrote:
Wed, 23 Sep 2009 10:43:53 -0400, Jeremie Pelletier thusly wrote:
You're right about concurrency being a different concept than threading,
but I wouldn't give threading away for a pure concurrent model either.
I believe D is aiming at giving progra
language_fan:
> [lot of stuff...]
> Switching to Python is in one way a step in
> the wrong direction - you lose something you already had for free -
> [lot of stuff...]
I know several languages but I'm usually able to write correct Python programs
(< 10_000 lines long) in less time than in ot
Robert Jacques wrote:
On Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier
wrote:
[snip]
Its the same for concurrency, I can think of vector processing,
functional calls, STM, message passing and shared memory off the top
of my head. All being valid models with each their pros and cons,
tog
On Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier
wrote:
[snip]
Its the same for concurrency, I can think of vector processing,
functional calls, STM, message passing and shared memory off the top of
my head. All being valid models with each their pros and cons, together
forming a com
language_fan wrote:
Fri, 25 Sep 2009 00:10:55 +, language_fan thusly wrote:
You
may disagree, but I find it much more pleasant to find that the
application does never crash even though it works 15% slower than an
optimal C++ code would.
Imagine if a buggy C++ program was monitoring your h
language_fan wrote:
Wed, 23 Sep 2009 10:43:53 -0400, Jeremie Pelletier thusly wrote:
You're right about concurrency being a different concept than threading,
but I wouldn't give threading away for a pure concurrent model either.
I believe D is aiming at giving programmers a choice of the tool
Lionello Lunesu wrote:
Andrei Alexandrescu wrote:
Max Samukha wrote:
On Thu, 24 Sep 2009 23:55:57 +0800, Lionello Lunesu
wrote:
Daniel Keep wrote:
Why not go with what C# uses?
class LotterySimulation : Lottery, Figure {
override void Lottery.draw();
override void Figure.draw();
}
Fri, 25 Sep 2009 00:10:55 +, language_fan thusly wrote:
> You
> may disagree, but I find it much more pleasant to find that the
> application does never crash even though it works 15% slower than an
> optimal C++ code would.
Imagine if a buggy C++ program was monitoring your health. If it cra
Wed, 23 Sep 2009 10:43:53 -0400, Jeremie Pelletier thusly wrote:
> You're right about concurrency being a different concept than threading,
> but I wouldn't give threading away for a pure concurrent model either.
> I believe D is aiming at giving programmers a choice of the tools they
> wish to
Wed, 23 Sep 2009 15:09:59 +1000, Daniel Keep thusly wrote:
> See, people equate "parallel execution" with "threads" these days which
> is half the problem. Threads are a TERRIBLE abstraction, because they
> don't. There's no protection. Almost every time I express the opinion
> that threads are
Andrei Alexandrescu wrote:
> Max Samukha wrote:
>> On Thu, 24 Sep 2009 23:55:57 +0800, Lionello Lunesu
>> wrote:
>>
>>> Daniel Keep wrote:
Why not go with what C# uses?
class LotterySimulation : Lottery, Figure {
override void Lottery.draw();
override void Figure.d
Max Samukha wrote:
> On Thu, 24 Sep 2009 23:55:57 +0800, Lionello Lunesu
> wrote:
>
>> Daniel Keep wrote:
>>> Why not go with what C# uses?
>>>
>>> class LotterySimulation : Lottery, Figure {
>>> override void Lottery.draw();
>>> override void Figure.draw();
>>> }
>>>
>>> Just seems like
Thu, 24 Sep 2009 18:00:56 -0400, bearophile thusly wrote:
> Walter Bright:
>
>> Executive summary: pure functions and immutable data structures help
>> manage program complexity.
>
> There's something missing in most of the articles I've read that praise
> pure functions and immutable data struc
Jeremie Pelletier wrote:
> downs wrote:
>> Jeremie Pelletier wrote:
>>> downs wrote:
Jeremie Pelletier wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> downs wrote:
Andrei Alexandrescu wrote:
> downs wrote:
>> With all the neat template tricks we
Compiling D Scintilla for DFL...
D:\D\dfl>D:\D\dmd2\windows\bin\dfl -c -debug -O -inline -I.. scintilla
Error checking versions; use switch -ver for details
D:\D\dmd2\windows\bin\dmd.exe -c -debug -O -inline -I.. scintilla
-version=DFL_E
XE -ID:\D\dmd2\windows\import -L/exet:nt/su:console:4.0
On Thu, 24 Sep 2009 16:31:56 -0400, dolive wrote:
Robert Jacques дµ½:
On Thu, 24 Sep 2009 14:21:55 -0400, dolive wrote:
> Robert Jacques �´µ½:
>
>> On Thu, 24 Sep 2009 06:22:57 -0400, dolive89
wrote:
>>
>> > can DFL make ide editor ?
>> > can do expansion of the corresponding func
Walter Bright:
> Executive summary: pure functions and immutable data structures help
> manage program complexity.
There's something missing in most of the articles I've read that praise pure
functions and immutable data structures. When I write a 500-lines long Python
program I often start us
Robert Jacques дµ½:
> On Thu, 24 Sep 2009 14:21:55 -0400, dolive wrote:
>
> > Robert Jacques ôµ½:
> >
> >> On Thu, 24 Sep 2009 06:22:57 -0400, dolive89 wrote:
> >>
> >> > can DFL make ide editor ?
> >> > can do expansion of the corresponding function?
> >>
> >> Yes.
> >> There's the Enti
Ary Borenszweig wrote:
>
> Is CommaExp what you are looking for?
That seems to be exactly what I'm looking for.
I did not know CommaExp did that.
This is most excellent. Now I can just integrate my code into
resolveProperties and be fairly certain that everything will work out.
Thank you!
Walter Bright wrote:
> Executive summary: pure functions and immutable data structures help
> manage program complexity.
I think so too, but you left out the time and identity part related to stm
and multiversion concurrency. You could argue these notions are a possible
consequence of immutab
Robert Jacques дµ½:
> On Thu, 24 Sep 2009 14:21:55 -0400, dolive wrote:
>
> > Robert Jacques ôµ½:
> >
> >> On Thu, 24 Sep 2009 06:22:57 -0400, dolive89 wrote:
> >>
> >> > can DFL make ide editor ?
> >> > can do expansion of the corresponding function?
> >>
> >> Yes.
> >> There's the Enti
Robert Jacques дµ½:
> On Thu, 24 Sep 2009 14:21:55 -0400, dolive wrote:
>
> > Robert Jacques ôµ½:
> >
> >> On Thu, 24 Sep 2009 06:22:57 -0400, dolive89 wrote:
> >>
> >> > can DFL make ide editor ?
> >> > can do expansion of the corresponding function?
> >>
> >> Yes.
> >> There's the Enti
downs wrote:
Jeremie Pelletier wrote:
downs wrote:
Jeremie Pelletier wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
downs wrote:
Andrei Alexandrescu wrote:
downs wrote:
With all the neat template tricks we have in 2.0, and since we're
widely redefining the syntax anyway, why not deprec
On Thu, 24 Sep 2009 23:36:46 +0400, Jarrett Billingsley
wrote:
On Thu, Sep 24, 2009 at 1:38 PM, Andrei Alexandrescu
wrote:
In Java, "protected"-level protection implies package-level protection
(see
e.g.
http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html).
Should we co
Walter Bright:
> Executive summary: pure functions and immutable data structures help
> manage program complexity.
At the moment in D there aren't many immutable data structures available, but
of course they can be written.
Such data structures often put the GC under some/high pressure. I don't
Executive summary: pure functions and immutable data structures help
manage program complexity.
Justin Johansson wrote:
Seriously though, I imagine the D design choices to be influenced by
the desire to propagate NaN and invalid UTF in their respective cases
so as to detect uninitialized data errors.
That's exactly what drove the design choices.
If there was a nan value for integers, D w
Thu, 24 Sep 2009 19:44:09 +, language_fan thusly wrote:
> Thu, 24 Sep 2009 15:33:38 -0400, Jarrett Billingsley thusly wrote:
>
>> On Thu, Sep 24, 2009 at 2:36 PM, Aenigmatic
>> wrote:
>>> No further response to any responses to my previous post's responses
>>> is a both swift and non-invasiv
Chad J wrote:
I'm spending some of my spare time implementing expression rewriting for
properties.
One thing I've noticed that bugs me is how resolveProperties is
scattered all over the place in statement.c and expression.c. I'm
wondering why it's called so zealously.
It bugs me because I'm wo
Chad J wrote:
>
> It bugs me because I'm worried that read properties can be generated by
> ...
>
I forgot to clarify. I meant read property /calls/.
Thu, 24 Sep 2009 15:33:38 -0400, Jarrett Billingsley thusly wrote:
> On Thu, Sep 24, 2009 at 2:36 PM, Aenigmatic
> wrote:
>> No further response to any responses to my previous post's responses is
>> a both swift and non-invasive.
>>
>> Now my deeply thought question is ...
>>
>> Is typedef (in D
On Thu, 24 Sep 2009 14:21:55 -0400, dolive wrote:
Robert Jacques дµ½:
On Thu, 24 Sep 2009 06:22:57 -0400, dolive89 wrote:
> can DFL make ide editor ?
> can do expansion of the corresponding function?
Yes.
There's the Entice IDE (http://www.dprogramming.com/entice.php)
Or the simpler DCod
I'm spending some of my spare time implementing expression rewriting for
properties.
One thing I've noticed that bugs me is how resolveProperties is
scattered all over the place in statement.c and expression.c. I'm
wondering why it's called so zealously.
It bugs me because I'm worried that read
On Thu, Sep 24, 2009 at 1:38 PM, Andrei Alexandrescu
wrote:
> In Java, "protected"-level protection implies package-level protection (see
> e.g.
> http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html).
> Should we copy that behavior in D, or take advantage of the package keyword
language_fan:
> Since your suggestion may add new syntactic constructs, can you somehow
> show that making the language more strict also improves overall program
> quality in some ways that unit testing and stronger type system cannot
> achieve.
In that example I've shown the possible syntax o
On Thu, Sep 24, 2009 at 2:36 PM, Aenigmatic wrote:
> No further response to any responses to my previous post's responses is a
> both swift and non-invasive.
>
> Now my deeply thought question is ...
>
> Is typedef (in D) a C/C++ legacy or is the dear orphan now adopted as a
> first-class citize
language_fan wrote:
Thu, 24 Sep 2009 13:47:21 -0400, Steven Schveighoffer thusly wrote:
I actually prefer the compiler to handle the casting versus templates to
cut down on template instantiation bloat.
I wonder how D scales to 100 MLOC programs as the template instantiations
can be troubles
Thu, 24 Sep 2009 21:13:48 +0200, downs thusly wrote:
> language_fan wrote:
>> Thu, 24 Sep 2009 13:47:21 -0400, Steven Schveighoffer thusly wrote:
>>
>>> I actually prefer the compiler to handle the casting versus templates
>>> to cut down on template instantiation bloat.
>>
>> I wonder how D sca
On Thu, 24 Sep 2009 14:36:01 -0400, Aenigmatic
wrote:
No further response to any responses to my previous post's responses is
a both swift and non-invasive.
Now my deeply thought question is ...
Is typedef (in D) a C/C++ legacy or is the dear orphan now adopted as a
first-class citizen
Jeremie Pelletier wrote:
> downs wrote:
>> Jeremie Pelletier wrote:
>>> grauzone wrote:
Andrei Alexandrescu wrote:
> downs wrote:
>> Andrei Alexandrescu wrote:
>>> downs wrote:
With all the neat template tricks we have in 2.0, and since we're
widely redefining the
language_fan wrote:
> Thu, 24 Sep 2009 13:47:21 -0400, Steven Schveighoffer thusly wrote:
>
>> I actually prefer the compiler to handle the casting versus templates to
>> cut down on template instantiation bloat.
>
> I wonder how D scales to 100 MLOC programs as the template instantiations
> can
downs wrote:
Jeremie Pelletier wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
downs wrote:
Andrei Alexandrescu wrote:
downs wrote:
With all the neat template tricks we have in 2.0, and since we're
widely redefining the syntax anyway, why not deprecate the current
cast syntax and move it
language_fan wrote:
Thu, 24 Sep 2009 14:36:01 -0400, Aenigmatic thusly wrote:
No further response to any responses to my previous post's responses is
a both swift and non-invasive.
Now my deeply thought question is ...
Is typedef (in D) a C/C++ legacy or is the dear orphan now adopted as a
fi
> I'd even like to have Pascal-inspired ranged integral values in D :-)
Once structs in D2 become flexible enough (with methods like opBool that get
called by if(x){}, etc) they can be used to define such ranged integer. I think
this flexibility improvement is a better strategy.
Bye,
bearophile
downs wrote:
bearophile wrote:
Justin Johansson:
See subject line
You can't. All questions here will be scrupulously scrubbed, looking for
subversive ideas or hidden irony, and if something is found they invariably
spout and blossom into invasive threads of often pointless but interesting
d
Thu, 24 Sep 2009 06:17:22 -0400, bearophile thusly wrote:
> There are other ways to make the language more strict, for example
> disallowing some automatic casts, etc. (C# already has some of this, for
> example float => double requires a cast. I don't remember if D2 requires
> this already).
Sin
Thu, 24 Sep 2009 14:36:01 -0400, Aenigmatic thusly wrote:
> No further response to any responses to my previous post's responses is
> a both swift and non-invasive.
>
> Now my deeply thought question is ...
>
> Is typedef (in D) a C/C++ legacy or is the dear orphan now adopted as a
> first-class
Thu, 24 Sep 2009 13:47:21 -0400, Steven Schveighoffer thusly wrote:
> I actually prefer the compiler to handle the casting versus templates to
> cut down on template instantiation bloat.
I wonder how D scales to 100 MLOC programs as the template instantiations
can be troublesome already in < 100
Aenigmatic:
>Is typedef (in D) a C/C++ legacy or is the dear orphan now adopted as a
>first-class citizen in the US of D? -- Yours truly, Justin Johansson<
The semantics of D typedef comes from Pascal, not from C.
It's useful, but unfortunately it's not a true first-class feature in D, its
purp
Jeremie Pelletier wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> downs wrote:
Andrei Alexandrescu wrote:
> downs wrote:
>> With all the neat template tricks we have in 2.0, and since we're
>> widely redefining the syntax anyway, why not deprecate the current
>> cast
bearophile wrote:
> Justin Johansson:
>> See subject line
>
> You can't. All questions here will be scrupulously scrubbed, looking for
> subversive ideas or hidden irony, and if something is found they invariably
> spout and blossom into invasive threads of often pointless but interesting
> dis
No further response to any responses to my previous post's responses is a both
swift and non-invasive.
Now my deeply thought question is ...
Is typedef (in D) a C/C++ legacy or is the dear orphan now adopted as a
first-class citizen in the US of D?
-- Yours truly, Justin Johansson
Robert Jacques дµ½:
> On Thu, 24 Sep 2009 06:22:57 -0400, dolive89 wrote:
>
> > can DFL make ide editor ?
> > can do expansion of the corresponding function?
>
> Yes.
> There's the Entice IDE (http://www.dprogramming.com/entice.php)
> Or the simpler DCode IDE(http://www.dprogramming.com/dcode
Justin Johansson:
>See subject line
You can't. All questions here will be scrupulously scrubbed, looking for
subversive ideas or hidden irony, and if something is found they invariably
spout and blossom into invasive threads of often pointless but interesting
discussions.
Bear hugs,
bearophile
Andrei Alexandrescu:
> In Java, "protected"-level protection implies package-level protection
> (see e.g.
> http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html).
> Should we copy that behavior in D, or take advantage of the package
> keyword and require it as in "package pro
See subject line
grauzone wrote:
Andrei Alexandrescu wrote:
downs wrote:
Andrei Alexandrescu wrote:
downs wrote:
With all the neat template tricks we have in 2.0, and since we're
widely redefining the syntax anyway, why not deprecate the current
cast syntax and move it into object.d as a library function?
So
On 24/09/2009 19:35, downs wrote:
With all the neat template tricks we have in 2.0, and since we're
widely redefining the syntax anyway, why not deprecate the current
cast syntax and move it into object.d as a library function?
So instead of cast(Foo) bar; you would say cast!Foo(bar); .. save on
Andrei Alexandrescu wrote:
In Java, "protected"-level protection implies package-level protection
(see e.g.
http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html).
Should we copy that behavior in D, or take advantage of the package
keyword and require it as in "package protect
On Thu, 24 Sep 2009 12:35:22 -0400, downs
wrote:
With all the neat template tricks we have in 2.0, and since we're widely
redefining the syntax anyway, why not deprecate the current cast syntax
and move it into object.d as a library function?
So instead of cast(Foo) bar; you would say ca
On 24/09/2009 16:30, Andrei Alexandrescu wrote:
Walter and I discussed last night about contravariance and all and could
not find a compelling argument in favor of implementing contravariant
arguments right now. The feature is nontrivial to implement, potentially
surprising, and has a number of o
In Java, "protected"-level protection implies package-level protection
(see e.g.
http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html).
Should we copy that behavior in D, or take advantage of the package
keyword and require it as in "package protected"?
Andrei
Andrei Alexandrescu wrote:
downs wrote:
Andrei Alexandrescu wrote:
downs wrote:
With all the neat template tricks we have in 2.0, and since we're
widely redefining the syntax anyway, why not deprecate the current
cast syntax and move it into object.d as a library function?
So instead of cast(
On Thu, 24 Sep 2009 12:47:12 -0400, grauzone wrote:
Steven Schveighoffer wrote:
The solution we ended up using is that *all* streams defined the seek
function, even if they didn't support seeking, and if you called it on
such objects, they just throw an exception.
So, if you want to see i
downs wrote:
Andrei Alexandrescu wrote:
downs wrote:
With all the neat template tricks we have in 2.0, and since we're
widely redefining the syntax anyway, why not deprecate the current
cast syntax and move it into object.d as a library function?
So instead of cast(Foo) bar; you would say cast
Andrei Alexandrescu wrote:
> downs wrote:
>> With all the neat template tricks we have in 2.0, and since we're
>> widely redefining the syntax anyway, why not deprecate the current
>> cast syntax and move it into object.d as a library function?
>>
>> So instead of cast(Foo) bar; you would say cast!
Sean Kelly wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
So I was thinking of this:
class LotterySimulation : Lottery, Figure {
override(Lottery) void draw();
override(Figure) void draw();
}
This is easy to implement, scales well, and has good real
downs wrote:
With all the neat template tricks we have in 2.0, and since we're widely
redefining the syntax anyway, why not deprecate the current cast syntax and
move it into object.d as a library function?
So instead of cast(Foo) bar; you would say cast!Foo(bar); .. save on a keyword
and dem
Max Samukha wrote:
On Thu, 24 Sep 2009 23:55:57 +0800, Lionello Lunesu
wrote:
Daniel Keep wrote:
Why not go with what C# uses?
class LotterySimulation : Lottery, Figure {
override void Lottery.draw();
override void Figure.draw();
}
Just seems like a more obvious and natural place fo
Steven Schveighoffer wrote:
The solution we ended up using is that *all* streams defined the seek
function, even if they didn't support seeking, and if you called it on
such objects, they just throw an exception.
So, if you want to see if an object supports seeking, you must call the
method +
On Thu, Sep 24, 2009 at 12:35 PM, downs wrote:
> With all the neat template tricks we have in 2.0, and since we're widely
> redefining the syntax anyway, why not deprecate the current cast syntax and
> move it into object.d as a library function?
>
> So instead of cast(Foo) bar; you would say ca
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
>
> So I was thinking of this:
> class LotterySimulation : Lottery, Figure {
> override(Lottery) void draw();
> override(Figure) void draw();
> }
> This is easy to implement, scales well, and has good real world u
With all the neat template tricks we have in 2.0, and since we're widely
redefining the syntax anyway, why not deprecate the current cast syntax and
move it into object.d as a library function?
So instead of cast(Foo) bar; you would say cast!Foo(bar); .. save on a keyword
and demonstrate langua
On Thu, 24 Sep 2009 23:55:57 +0800, Lionello Lunesu
wrote:
>Daniel Keep wrote:
>> Why not go with what C# uses?
>>
>> class LotterySimulation : Lottery, Figure {
>> override void Lottery.draw();
>> override void Figure.draw();
>> }
>>
>> Just seems like a more obvious and natural place
On Thu, 24 Sep 2009 09:30:46 -0400, Andrei Alexandrescu
wrote:
Walter and I discussed last night about contravariance and all and could
not find a compelling argument in favor of implementing contravariant
arguments right now. The feature is nontrivial to implement, potentially
surprising,
On Thu, 24 Sep 2009 11:53:13 -0400, Jeremie Pelletier
wrote:
Steven Schveighoffer wrote:
The Tango lib used to define Input and Output streams independent of
Seekable streams (there was a Seek interface which was applied
separately to an input/output implementation class).
But what ends
On Thu, 24 Sep 2009 06:22:57 -0400, dolive89 wrote:
can DFL make ide editor ?
can do expansion of the corresponding function?
Yes.
There's the Entice IDE (http://www.dprogramming.com/entice.php)
Or the simpler DCode IDE(http://www.dprogramming.com/dcode.php)
Or the Scintilla control if you w
Daniel Keep wrote:
> Why not go with what C# uses?
>
> class LotterySimulation : Lottery, Figure {
> override void Lottery.draw();
> override void Figure.draw();
> }
>
> Just seems like a more obvious and natural place for it to me. D
> already uses this to disambiguate symbols in other
Steven Schveighoffer wrote:
On Thu, 24 Sep 2009 10:54:06 -0400, Jeremie Pelletier
wrote:
Steven Schveighoffer wrote:
On Tue, 22 Sep 2009 22:02:59 -0400, Jeremie Pelletier
wrote:
Yeah most of my display interfaces would make use of covariant
arguments, I use main abstract factory for the
> Something that may be useful, partially related:
> http://en.wikipedia.org/wiki/Multiple_dispatch
> http://en.wikipedia.org/wiki/Generic_function
Something similar to the CLisp syntax looks good enough for D (I think there's
no need to add an explicit mark that reminds there's some runtime cost
Andrei Alexandrescu:
> Walter and I discussed last night about contravariance and all and could
> not find a compelling argument in favor of implementing contravariant
> arguments right now. The feature is nontrivial to implement, potentially
> surprising, and has a number of odd corner cases.
On Thu, 24 Sep 2009 10:54:06 -0400, Jeremie Pelletier
wrote:
Steven Schveighoffer wrote:
On Tue, 22 Sep 2009 22:02:59 -0400, Jeremie Pelletier
wrote:
Yeah most of my display interfaces would make use of covariant
arguments, I use main abstract factory for the entire package, and the
Hello Walter,
Don wrote:
If you provide slice access (eg, give me elements [a..b] as an array
of ints) then you can have reasonable performance. Unpacking
consecutive elements can be done quite efficiently (it's an
interesting optimisation problem, though!).
It wouldn't be slicable because a
Steven Schveighoffer wrote:
On Thu, 24 Sep 2009 09:30:46 -0400, Andrei Alexandrescu
wrote:
Walter and I discussed last night about contravariance and all and
could not find a compelling argument in favor of implementing
contravariant arguments right now. The feature is nontrivial to
impleme
Daniel Keep wrote:
Andrei Alexandrescu wrote:
...
So I was thinking of this:
class LotterySimulation : Lottery, Figure {
override(Lottery) void draw();
override(Figure) void draw();
}
This is easy to implement, scales well, and has good real world uses.
What say you?
Andrei
Why n
Daniel Keep:
> Why not go with what C# uses?
>
> class LotterySimulation : Lottery, Figure {
> override void Lottery.draw();
> override void Figure.draw();
> }
Looks good enough, I can understand it. For the programmers out there it's
positive to use a syntax already in use (especially
So I was thinking of this:
class LotterySimulation : Lottery, Figure {
override(Lottery) void draw();
override(Figure) void draw();
}
This is easy to implement, scales well, and has good real world uses.
What say you?
Andrei
I think this is well solved in C#
http://msdn.microsoft.com/en-us
Andrei Alexandrescu wrote:
Walter and I discussed last night about contravariance and all and could
not find a compelling argument in favor of implementing contravariant
arguments right now. The feature is nontrivial to implement, potentially
surprising, and has a number of odd corner cases.
1 - 100 of 119 matches
Mail list logo
