Rainer Deyke wrote:
Andrei Alexandrescu wrote:
interface Cloneable(T) if (is(T == class))
{
private T doClone(); // must implement but can't call
T clone()// this is what everybody can call
{
auto result = doClone();
assert(typeof(result) == typeof(this));
Walter Bright:
> Some languages generate lots of allocations for other reasons, such as
> lack of value aggregates that can be put on the stack.
This is true.
But I have no idea how much Haskell/Clojure/F#/OCaML/etc use the stack to
allocate temporary things. I'd like to know more about this. I
Andrei Alexandrescu wrote:
> interface Cloneable(T) if (is(T == class))
> {
> private T doClone(); // must implement but can't call
> T clone()// this is what everybody can call
> {
> auto result = doClone();
> assert(typeof(result) == typeof(this));
>
Andrei Alexandrescu wrote:
This feature would require changing some protection rules, I think for
the better. What do you think?
1. what are those changes?
2. did you mean to add executable code to an interface?
bearophile wrote:
Walter Bright:
I've been thinking of transitioning dmd's semantic analysis to
using immutable data structures because it will reduce allocations,
not increase them.<
As usual I am ignorant about such matters, so I can't give you a good
answer. But from what I've seen in immu
Andrei Alexandrescu Wrote:
> In this article:
>
> http://www.gotw.ca/publications/mill18.htm
>
> Herb Sutter makes a powerful argument that overridable functions
> (customization points) should actually not be the same as the publically
> available interface. This view rhymes with the Template
Hello Gzp,
Hello,
I'm quite new to D, and it seems to be a great language for me. But
I've some questions:
Hi!
Why is it good to treat functions as property, it make the code quite
unreadable. With a simple property keyword the things were much clear,
like:
class Foo {
property prop {
Adam D. Ruppe:
> macro max(int a, int b) {
> return a ~ " > " ~ b ~ " ? " ~ a ~ " : " ~ b;
> }
In std.metastrings there's Format that allows to use a basic form of string
templating, that I find a little more readable than many string concats:
return a ~ " > " ~ b ~ " ? " ~ a ~ " : " ~ b;
Walter Bright:
>I've been thinking of transitioning dmd's semantic analysis to using immutable
>data structures because it will reduce allocations, not increase them.<
As usual I am ignorant about such matters, so I can't give you a good answer.
But from what I've seen in immutable-based languag
Rich Hickey:
>No, I don't. The post is for Clojure users and shows them a relative
>comparison they care about, persistent vs transient.<
>Unless that code is returning a persistent vector and provides thread
>isolation, it is not doing the same job.<
Sorry, I didn't mean to offend you in any w
On Fri, Sep 25, 2009 at 7:31 PM, Jeremie Pelletier wrote:
> language_fan wrote:
>> A used 2.5 GHz Athlon XP with 1GB of RAM and 100GB of disk costs about
>> $100. Anything below that is obsolete these days. Good luck selling anything
>> to people who use older computers, they are probably broke an
Jason House wrote:
Walter Bright Wrote:
bearophile wrote:
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
str
language_fan wrote:
> I do not believe the market works this way. According to that logic
> popularity correlates with expenses. So if you have e.g. 1 billion users,
> even $1 in per-user hardware costs causes a billion dollar losses to
> customers. Is that unacceptable? On the other hand a prog
Walter Bright Wrote:
> bearophile wrote:
> > 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.
> >
Rich Hickey wrote:
Rich (Early Zortech user and fan, btw)
Thanks, and thanks for stopping by and commenting in this thread.
bearophile wrote:
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
language_fan wrote:
Thu, 24 Sep 2009 22:58:51 -0600, Rainer Deyke thusly wrote:
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 enthusiast
Thu, 24 Sep 2009 22:58:51 -0600, Rainer Deyke thusly wrote:
> 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 compu
bearophile Wrote:
> Rich Hickey:
>
> > You might find this interesting:
> > http://clojure.org/transients
> > It supports using the exact same immutable data structures in/out of your
> > (externally pure) function, as well as the exact same functional "shape" of
> > your code when using transi
On Sat, 26 Sep 2009 00:49:27 +0400, Andrei Alexandrescu
wrote:
In this article:
http://www.gotw.ca/publications/mill18.htm
Herb Sutter makes a powerful argument that overridable functions
(customization points) should actually not be the same as the publically
available interface. This
In this article:
http://www.gotw.ca/publications/mill18.htm
Herb Sutter makes a powerful argument that overridable functions
(customization points) should actually not be the same as the publically
available interface. This view rhymes with the Template Method pattern
as well.
This leads to
http://prowiki.org/wiki4d/wiki.cgi?DocComments/Property
On Fri, Sep 25, 2009 at 09:29:21AM +0200, Don wrote:
> I demonstrated that the combination of CTFE + string mixins,
> even in D1, was dramatically more powerful than the proposed macros. It
> became clear that we didn't have a macro design that was anywhere near
> powerful enough, and macros wer
On Fri, 25 Sep 2009 03:29:21 -0400, Don wrote:
[snip]
A bit of history: A macro system was planned for D2, and 'macro' was
made a reserved word. But in discussions at the end of the first D
conference, I demonstrated that the combination of CTFE + string mixins,
even in D1, was dramatically
Rich Hickey:
> You might find this interesting:
> http://clojure.org/transients
> It supports using the exact same immutable data structures in/out of your
> (externally pure) function, as well as the exact same functional "shape" of
> your code when using transients (roughly, mutables) internal
bearophile 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 structures. When I write a 500-lines long
Don wrote:
> 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 i
Thanks, i've found it.
Gzp
Chad J wrote:
> typedef uint ColorFormat;
> enum : ColorFormat
> {
> RGB,
> RGBA,
> HSV,
> CMYK,
> // etc
> }
I always do the opposite in C++:
namespace color_formats {
enum ColorFormat {
RGB,
RGBA,
HSV,
CMYK,
// ...
};
}
using color_formats::
Lars T. Kyllingstad wrote:
Gzp wrote:
Hello,
I'm quite new to D, and it seems to be a great language for me.
But I've some questions:
Why is it good to treat functions as property, it make the code quite
unreadable. With a simple property keyword the things were much clear,
like:
Hello, and
Gzp wrote:
Hello,
I'm quite new to D, and it seems to be a great language for me.
But I've some questions:
Why is it good to treat functions as property, it make the code quite
unreadable. With a simple property keyword the things were much clear, like:
Hello, and welcome! :)
There was a HUG
Hello,
I'm quite new to D, and it seems to be a great language for me.
But I've some questions:
Why is it good to treat functions as property, it make the code quite
unreadable. With a simple property keyword the things were much clear, like:
class Foo {
property prop {
int get {
re
cemiller дµ½:
> >
> > 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\
Robert Jacques дµ½:
> 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:
> >> >>
> >>
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
Chad J wrote:
> H, there's a lot of hating on typedef.
>
> I've found it rather useful for at least one thing:
>
> typedef uint ColorFormat;
> enum : ColorFormat
> {
> RGB,
> RGBA,
> HSV,
> CMYK,
> // etc
> }
>
> Now you have an enum that is type safe but doesn'
H, there's a lot of hating on typedef.
I've found it rather useful for at least one thing:
typedef uint ColorFormat;
enum : ColorFormat
{
RGB,
RGBA,
HSV,
CMYK,
// etc
}
Now you have an enum that is type safe but doesn't require a qualified
name to use.
language_fan wrote:
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
38 matches
Mail list logo
