Walter Bright wrote:
If we can get anywhere close to that level of success with ranges and
containers, we should all be well pleased.
Mike Taylor has a phrase for that I think is well-coined: "impedance matching",
defined as the work necessary to get one library module to work with another
li
Andrei Alexandrescu Wrote:
>
> I don't know Tango, but Java's containers are a terrible example to
> follow. Java's container library is a ill-advised design on top of an
> underpowered language, patched later with some half-understood seeming
> of genericity. I think Java containers are a huge
Hello Andrei,
On 05/20/2010 08:22 AM, Steven Schveighoffer wrote:
Michel Fortin Wrote:
On 2010-05-20 06:34:42 -0400, Steven
Schveighoffer said:
I understand these points, but I'm already using interfaces to copy
data between containers. I don't have to, I could have used
generic code, but
Hello Vladimir,
On Thu, 20 May 2010 04:42:35 +0300, Steven Schveighoffer
wrote:
interfaces
Does that imply that the most important methods are virtual?
If so, say good-bye to inlining, and hello to an additional level of
dereferencing.
From a technical standpoint there is no reason that
Hello BLS,
ok Some collection types belong to the same family. So they should be
loosely coupled. How to do that without having Interfaces ?
How about this: Make a flat family of collections. Name the methods so that
across the lib, the same name does the same kind of thing and different nam
Hello Bill,
On Fri, May 21, 2010 at 9:43 AM, Steven Schveighoffer
wrote:
void foo(int[int] x)
{
x[5] = 5;
}
void main()
{
int[int] x;
foo(x);
assert(x[5] == 5); // fails
}
And with arrays at least it's even more insidious, because sometimes
it will seem to work, and sometimes it won't.
void
Hello superdan,
dun tell me it dun work. i dun explain shit again. it works coz a
struct cant be null. but a struct can be a ref if it only haz one
pointer inside. methinks the builtin hash iz dat way.
void foo(container!shit poo)
{
if(!poo) poo = new container!shit; // fuck dat shit
poo.ad
On Thu, 20 May 2010 04:42:35 +0300, Steven Schveighoffer
wrote:
interfaces
Does that imply that the most important methods are virtual?
If so, say good-bye to inlining, and hello to an additional level of
dereferencing.
Without meaning any disrespect to all the work you did, allow me t
Walter Bright wrote:
If we can get anywhere close to that level of success with ranges and
containers, we should all be well pleased.
Mike Taylor has a phrase for that I think is well-coined: "impedance matching",
defined as the work necessary to get one library module to work with another
libr
Andrei Alexandrescu wrote:
On 05/19/2010 09:59 PM, Robert Jacques wrote:
Yes and No. I understand where your coming from, but I think it's a bad
idea. First, I think it needlessly expands the radius of comprehension
needed to understand and use the library. (See Tangled up in tools
http://www.pr
On 21/05/2010 19:15, Andrei Alexandrescu wrote:
I'll now slowly answer the great replies I got in this thread, in
chronological order. Since I read them all before replying, I might
sometimes refer to future posts. Hopefully that won't be too confusing.
Andrei
Following the dcollection thread,
Steven Schveighoffer wrote:
I myself don't really use the interface aspect of the classes, it is mostly a
carryover from the Java/Tango inspirations. But I can see one good reason to
keep them -- binary interoperability. For example, it might be the case some
day when D has good support wit
Andrei Alexandrescu wrote:
See the -mergefunc compiler switch of LDC, to merge identical
functions (like ones produced by template instantiations). This
feature is not very powerful yet, but it's present and I have seen it
works.
Indeed. I'm no expert in linkers, but in my opinion this is one o
On 05/21/2010 01:34 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
I wrote a solution to the problem in native D. It goes like this:
alias Container!(int, addable | purgeable) Messerschmidt;
void messWith(Messerschmidt i) {
... use i's capabilities to add and purge ...
}
I agree with Mi
Andrei Alexandrescu wrote:
I wrote a solution to the problem in native D. It goes like this:
alias Container!(int, addable | purgeable) Messerschmidt;
void messWith(Messerschmidt i) {
... use i's capabilities to add and purge ...
}
I agree with Michael Fortin that the | is questionable. I
On Fri, May 21, 2010 at 10:50 AM, superdan wrote:
>> void foo(int[int] x)
>> {
>> x[5] = 5;
>> }
>> void main()
>> {
>> int[int] x;
>> foo(x);
>> assert(x[5] == 5); // fails
>> }
>> -Steve
>
> wrote a long post but it got lost. shit. bottom line dats a bug in dmd or
> phobos.
Unfort
On 05/20/2010 02:47 PM, bearophile wrote:
Michel Fortin:
Devirtualization is only possible in certain cases: when the
function knows exactly which type it'll get.<
You are wrong, in most cases there are ways to de-virtualize, even
when the runtime type isn't exactly known, but sometimes to do
On 05/20/2010 09:41 AM, Michel Fortin wrote:
On 2010-05-20 08:30:59 -0400, bearophile said:
Michel Fortin:
Surely going through all those virtual calls slows things down a lot.<
Right. But the purpose of a good compiler is to kill those,
devirtualizing. LLVM devs are working on this too. S
On 05/20/2010 09:14 AM, Pelle wrote:
On 05/20/2010 03:22 PM, Steven Schveighoffer wrote:
One thing I just thought of -- in dcollections, similar types can be
compared to one another. For example, you can check to see if a
HashSet is equal to a TreeSet. But that would not be possible without
inte
On 05/20/2010 06:17 AM, Michel Fortin wrote:
On 2010-05-20 06:34:42 -0400, Steven Schveighoffer
said:
I understand these points, but I'm already using interfaces to copy
data between containers. I don't have to, I could have used generic
code, but this way, only one function is instantiated to
On 05/20/2010 08:22 AM, Steven Schveighoffer wrote:
Michel Fortin Wrote:
On 2010-05-20 06:34:42 -0400, Steven
Schveighoffer said:
I understand these points, but I'm already using interfaces to
copy data between containers. I don't have to, I could have used
generic code, but this way, only
On 05/20/2010 05:34 AM, Steven Schveighoffer wrote:
Robert Jacques Wrote:
On Wed, 19 May 2010 21:42:35 -0400, Steven Schveighoffer
Does that make sense?
-Steve
Yes and No. I understand where your coming from, but I think it's a
bad idea. First, I think it needlessly expands the radius of
c
On 05/19/2010 09:59 PM, Robert Jacques wrote:
On Wed, 19 May 2010 21:42:35 -0400, Steven Schveighoffer
wrote:
Andrei Alexandrescu Wrote:
To get back to one of my earlier points, the fact that the container
interfaces are unable to express iteration is a corollary of the
design's problem and
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> superdan Wrote:
> > == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> > > superdan Wrote:
> > > > == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> > > > > Is there some other reason to use st
On 05/19/2010 09:48 PM, Michel Fortin wrote:
On 2010-05-19 19:01:51 -0400, Andrei Alexandrescu
said:
I wrote a solution to the problem in native D. It goes like this:
alias Container!(int, addable | purgeable) Messerschmidt;
void messWith(Messerschmidt i) {
... use i's capabilities to add an
On 05/19/2010 08:53 PM, Steven Schveighoffer wrote:
bearophile Wrote:
Andrei Alexandrescu:
Destroy me :o).
You ideas are surely interesting, but I don't think there's a
simple way to change his code according to your ideas.
I don't think the ideas are mutually exclusive. I don't see why
h
On 05/19/2010 08:42 PM, Steven Schveighoffer wrote:
Andrei Alexandrescu Wrote:
To get back to one of my earlier points, the fact that the
container interfaces are unable to express iteration is a corollary
of the design's problem and an climactic disharmony.
My vision, in very brief, is to fo
On 05/19/2010 07:57 PM, Bill Baxter wrote:
On Wed, May 19, 2010 at 4:01 PM, Andrei Alexandrescu
wrote:
My vision, in very brief, is to foster a federation of independent
containers abiding to identical names for similar functionality. Then a few
concept checks (a la std.range checks) can easi
On 05/19/2010 07:21 PM, bearophile wrote:
Andrei Alexandrescu:
Destroy me :o).
You ideas are surely interesting, but I don't think there's a simple
way to change his code according to your ideas. People can use the
dcollections in the following weeks and months, and when you have
implemented y
On 05/21/2010 11:55 AM, Ellery Newcomer wrote:
On 05/21/2010 09:14 AM, Steven Schveighoffer wrote:
Second, since reference types are the right thing to do, classes are
much easier to deal with. I know AA's are reference types that are
structs, but the code needed to perform this feat is not triv
I'll now slowly answer the great replies I got in this thread, in
chronological order. Since I read them all before replying, I might
sometimes refer to future posts. Hopefully that won't be too confusing.
Andrei
On Fri, May 21, 2010 at 9:43 AM, Steven Schveighoffer
wrote:
> superdan Wrote:
>
>> == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
>> > superdan Wrote:
>> > > == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
>> > > > Is there some other reason to use structs b
On 05/21/2010 09:14 AM, Steven Schveighoffer wrote:
Second, since reference types are the right thing to do, classes are much
easier to deal with. I know AA's are reference types that are structs, but the
code needed to perform this feat is not trivial. The AA has only one member, a
referenc
superdan Wrote:
> == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> > superdan Wrote:
> > > == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> > > > Is there some other reason to use structs besides copy construction?
> > > > -Steve
> > >
> > > memory managemen
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> superdan Wrote:
> > == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> > > Is there some other reason to use structs besides copy construction?
> > > -Steve
> >
> > memory management n shit. with a struct u can u
superdan Wrote:
> == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> > Is there some other reason to use structs besides copy construction?
> > -Steve
>
> memory management n shit. with a struct u can use refcounting n malloc n
> realloc n
> shit. still stays a reference type.
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> superdan Wrote:
> > == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> > > Andrei Alexandrescu Wrote:
> > > > To get back to one of my earlier points, the fact that the container
> > > > interfaces are unable to
superdan Wrote:
> == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> > Andrei Alexandrescu Wrote:
> > > To get back to one of my earlier points, the fact that the container
> > > interfaces are unable to express iteration is a corollary of the
> > > design's problem and an climac
38 matches
Mail list logo
