Re: SHOO's time code
On Tue, 18 May 2010 14:10:05 -0400, Moritz Warning wrote: On Tue, 18 May 2010 14:24:40 +, superdan wrote: == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article On Tue, 18 May 2010 09:39:12 -0400, superdan wrote: > guys go with boost and std.gregorian n shit. sorry shoo. tango is a > fucking boat anchor for d. shit. Having written most of the API for tango.time, I sorta like it :) I really like the API that SHOO came up with based on it. If there's any way to get SHOO's code into Phobos, I want to pursue that first. If this fails, we can go with boost. -Steve i feel ya bro. i once sorta liked a hoe with herpes. way i c it is simple. it's fucking dates and fucking times. wut the fuck. ain't a fucking operating system. no matter how u dress a pig u still call it a fucking pig. if u have da datetime functionality it don't matter to be cute. we is wasting time sucking lars douche's cock 2 give us permission 2 his fucking shit. fuck that shit. dis must be da least amount of power that got to some idiot's head. Wut? Person A wrote some code and had a look at code from person B. Now person C says that A need to get permission from B so that C can use the code from A. The reason is because the license of the code written by B isn't quite compatible with the license recently chosen by C. And now you are calling B an idiot/douche for that reason? Let's make it a bit clearer. Person A *used* the code from person B, and used the *documentation* of said code to write his own similar library. Person A has not claimed that he looked at the source. Person B claims that it is impossible to do so without actually looking at the source, but has not yet cited any specific copying. Person C doesn't want any trouble, and just is being extra careful. I don't really like the situation, but if this is the way it has to be, then let's get it done and move on. -Steve
dcollections 1.0 and 2.0a beta released
After much work and toil, I have created dcollections for D2. I think I can say that this is the first collection package available for D2. I still hold hope that it will be used as the standard collection package for phobos for D2. Please visit http://www.dsource.org/projects/dcollections for details. Some VERY IMPORTANT notes for this release: 1. it is very beta software. Although the implementation has changed very little from the 1.0 version, not everything will properly compile. I have filed several compiler bugs to fix some problems I had while porting, and inserted workarounds for things I could work around. Please use the LATEST compiler (currently 2.046) because some very important features have been added that dcollections relies on. Although it is beta, the algorithms and implementation is largely unchanged so functionality should be pretty solid. 2. the docs are not online for d2. Unfortunately, dsource's auto-doc-generator that I was using for the 1.0 version is based on a 1.0 compiler, so it will not automatically generate the d2 docs. However, I have included some basic ddoc generated docs in the download package, don't expect them to be very fun to use :) 3. The docs are not fully updated, so they might be just flat out wrong! I plan to update the docs completely for the next beta release. So, for the good stuff... here are some notes for differences between 1.0 and 2.0: * Ranges! * Filled out slicing for all containers * Cursors are now non-movable. Use ranges for safe iteration. * The interfaces have been cut down significantly. The question I asked myself when deciding whether I wanted to keep an interface is "would anyone use this interface?" * Functions that should be fast but can be slow (O(n)) have been removed from all interfaces, and in most cases, from the containers. Notably missing is searching a non-quick lookup container for a value. Use std.algorithm.find for that. * ArrayMultiset has been removed -- it's complexity functions did not fit with the multiset requirements (specifically, quick lookup of an element's presence). * ArrayList slicing now simply returns a range instead of a "live" slice. Note that an ArrayList range is aliased to a D array. * Full unit tests added for all container types. I have also changed the license from BSD to Boost. I have also formally released version 0.03 as version 1.0, nothing has changed there, including the license. However, no new features will be added to dcollections version 1.0, only bug fixes will be done. Please, file tickets on dsource for any problems you have. And let me know if there are any ideas you think would be useful. -Steve
Re: dcollections 1.0 and 2.0a beta released
Thanks Steven. I was waiting for this for a long time. On Wed, 19 May 2010 11:09:11 -0500, Steven Schveighoffer wrote: After much work and toil, I have created dcollections for D2. I think I can say that this is the first collection package available for D2. I still hold hope that it will be used as the standard collection package for phobos for D2. Please visit http://www.dsource.org/projects/dcollections for details. Some VERY IMPORTANT notes for this release: 1. it is very beta software. Although the implementation has changed very little from the 1.0 version, not everything will properly compile. I have filed several compiler bugs to fix some problems I had while porting, and inserted workarounds for things I could work around. Please use the LATEST compiler (currently 2.046) because some very important features have been added that dcollections relies on. Although it is beta, the algorithms and implementation is largely unchanged so functionality should be pretty solid. 2. the docs are not online for d2. Unfortunately, dsource's auto-doc-generator that I was using for the 1.0 version is based on a 1.0 compiler, so it will not automatically generate the d2 docs. However, I have included some basic ddoc generated docs in the download package, don't expect them to be very fun to use :) 3. The docs are not fully updated, so they might be just flat out wrong! I plan to update the docs completely for the next beta release. So, for the good stuff... here are some notes for differences between 1.0 and 2.0: * Ranges! * Filled out slicing for all containers * Cursors are now non-movable. Use ranges for safe iteration. * The interfaces have been cut down significantly. The question I asked myself when deciding whether I wanted to keep an interface is "would anyone use this interface?" * Functions that should be fast but can be slow (O(n)) have been removed from all interfaces, and in most cases, from the containers. Notably missing is searching a non-quick lookup container for a value. Use std.algorithm.find for that. * ArrayMultiset has been removed -- it's complexity functions did not fit with the multiset requirements (specifically, quick lookup of an element's presence). * ArrayList slicing now simply returns a range instead of a "live" slice. Note that an ArrayList range is aliased to a D array. * Full unit tests added for all container types. I have also changed the license from BSD to Boost. I have also formally released version 0.03 as version 1.0, nothing has changed there, including the license. However, no new features will be added to dcollections version 1.0, only bug fixes will be done. Please, file tickets on dsource for any problems you have. And let me know if there are any ideas you think would be useful. -Steve -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: dcollections 1.0 and 2.0a beta released
Are the collections supposed to not have isEmpty members? Looking forward to using dcollections, and here's to hoping they make it into phobos. OTish: What are your thoughts on a bimap implementation and a child/sibling or general tree implementation as part of dcollections?
Re: dcollections 1.0 and 2.0a beta released
Sheer awesomeness! I've been waiting for along time for a decent collections lib for D2. I haven't tested it extensively, but it definitely builds w/o a hitch (using a custom build script I wrote that builds dcollections and other libs I use in one go) and works for the toy examples I tested. One small comment, though: Looking at your ArrayList code, wouldn't it make more sense to use a capacity field here than to use the builtin array appending mechanism, given that this is a class, not a struct?
Re: dcollections 1.0 and 2.0a beta released
Ellery Newcomer Wrote: > Are the collections supposed to not have isEmpty members? No. Use length == 0. O(1) length is always supported for all collections. > OTish: What are your thoughts on a bimap implementation and a > child/sibling or general tree implementation as part of dcollections? I haven't the slightest what a bimap is :) I am not an expert in collections or data structures, I just reimplement things I have understood. My implementations are basically copied from my algorithm book, and refined as much as I can do. That being said, if you have any implementation of a tree or hash, it should be easy to insert into dcollections. If you have ideas for other collection types (i.e. other than Map, Set, Multiset or List), then I can look into that if you point me at an implementation or have one of your own. I purposefully left out multi-map because I've never had a huge use for it, and it seemed like a awkward thing to create an interface for... -Steve
Re: dcollections 1.0 and 2.0a beta released
dsimcha Wrote: > One small comment, though: Looking at your ArrayList code, wouldn't it make > more > sense to use a capacity field here than to use the builtin array appending > mechanism, given that this is a class, not a struct? Yes, that is part of my semi-documented long term plan. I actually am planning on adding an "extendLength" runtime function to support extending the length of an array as much as possible without reallocating. That way I can make ArrayList independent of the allocation sizes that the GC supports. -Steve
Re: dcollections 1.0 and 2.0a beta released
Hi Steven, On Wed, 19 May 2010 12:09:11 -0400, Steven Schveighoffer wrote: > After much work and toil, I have created dcollections for D2. I think I > can say that this is the first collection package available for D2. I > still hold hope that it will be used as the standard collection package > for phobos for D2. Cool! In case anyone's interested, I tried out dcollections using my very alpha 'd-build' script, and it works just fine: http://github.com/gmfawcett/d-build/tree/dcollections-test tarball of the dcollections test branch: http://github.com/gmfawcett/d-build/tarball/dcollections-test Checking out the 'dcollections-test' branch of that git project, you should be able to just run './d-build test.d' and it will first download dcollections and then compile it along with the test program. There are several limitations; see the README for details. There's a long way to go before d-build is more than a toy. But I'd like to keep it on people's radars, and am interested in your thoughts and feedback. See the "envy for go packages" threads on this list for context. Regards, Graham > > Please visit http://www.dsource.org/projects/dcollections for details. > > Some VERY IMPORTANT notes for this release: > > 1. it is very beta software. Although the implementation has changed > very little from the 1.0 version, not everything will properly compile. > I have filed several compiler bugs to fix some problems I had while > porting, and inserted workarounds for things I could work around. > Please use the LATEST compiler (currently 2.046) because some very > important features have been added that dcollections relies on. > Although it is beta, the algorithms and implementation is largely > unchanged so functionality should be pretty solid. > > 2. the docs are not online for d2. Unfortunately, dsource's > auto-doc-generator that I was using for the 1.0 version is based on a > 1.0 compiler, so it will not automatically generate the d2 docs. > However, I have included some basic ddoc generated docs in the download > package, don't expect them to be very fun to use :) > > 3. The docs are not fully updated, so they might be just flat out wrong! > I plan to update the docs completely for the next beta release. > > So, for the good stuff... here are some notes for differences between > 1.0 and 2.0: > > * Ranges! > * Filled out slicing for all containers * Cursors are now > non-movable. Use ranges for safe iteration. * The interfaces have > been cut down significantly. The question I > asked myself when deciding whether I wanted to keep an interface is > "would anyone use this interface?" > * Functions that should be fast but can be slow (O(n)) have been > removed from all interfaces, and in most cases, from the containers. > Notably missing is searching a non-quick lookup container for a value. > Use std.algorithm.find for that. > * ArrayMultiset has been removed -- it's complexity functions did > not > fit with the multiset requirements (specifically, quick lookup of an > element's presence). > * ArrayList slicing now simply returns a range instead of a "live" > slice. Note that an ArrayList range is aliased to a D array. > * Full unit tests added for all container types. > > I have also changed the license from BSD to Boost. > > > > > I have also formally released version 0.03 as version 1.0, nothing has > changed there, including the license. However, no new features will be > added to dcollections version 1.0, only bug fixes will be done. > > Please, file tickets on dsource for any problems you have. And let me > know if there are any ideas you think would be useful. > > -Steve
Re: dcollections 1.0 and 2.0a beta released
On Wed, 19 May 2010 20:27:17 +, Graham Fawcett wrote: > Hi Steven, > > On Wed, 19 May 2010 12:09:11 -0400, Steven Schveighoffer wrote: > >> After much work and toil, I have created dcollections for D2. I think >> I can say that this is the first collection package available for D2. >> I still hold hope that it will be used as the standard collection >> package for phobos for D2. > > Cool! > > In case anyone's interested, I tried out dcollections using my very > alpha 'd-build' script, and it works just fine: > > http://github.com/gmfawcett/d-build/tree/dcollections-test > > tarball of the dcollections test branch: > http://github.com/gmfawcett/d-build/tarball/dcollections-test > > Checking out the 'dcollections-test' branch of that git project, you > should be able to just run './d-build test.d' and it will first download > dcollections and then compile it along with the test program. There are > several limitations; see the README for details. > > There's a long way to go before d-build is more than a toy. But I'd like > to keep it on people's radars, and am interested in your thoughts and > feedback. See the "envy for go packages" threads on this list for > context. Apologies; the "envy for go packages" thread is on the D list, not on D.announce. Graham
Re: dcollections 1.0 and 2.0a beta released
On 05/19/2010 03:07 PM, Steven Schveighoffer wrote: Ellery Newcomer Wrote: Are the collections supposed to not have isEmpty members? No. Use length == 0. O(1) length is always supported for all collections. OTish: What are your thoughts on a bimap implementation and a child/sibling or general tree implementation as part of dcollections? I haven't the slightest what a bimap is :) I am not an expert in collections or data structures, I just reimplement things I have understood. My implementations are basically copied from my algorithm book, and refined as much as I can do. I think boost.bimap is where I saw it, though I don't don't use c++. I think it's a map, with values->keys is also a map That being said, if you have any implementation of a tree or hash, it should be easy to insert into dcollections. If you have ideas for other collection types (i.e. other than Map, Set, Multiset or List), then I can look into that if you point me at an implementation or have one of your own. I purposefully left out multi-map because I've never had a huge use for it, and it seemed like a awkward thing to create an interface for... -Steve I have a simple child/sibling tree implementation which I could probably dust off and polish up if you want it. The method for visiting the elements is kind of weird, though. And I don't know that it exactly fits the mold of a reference container. Maybe with cursors. Ugh, I just noticed LinkList doesn't work with interfaces.
Re: dcollections 1.0 and 2.0a beta released
Steven Schveighoffer Wrote: > After much work and toil, I have created dcollections for D2. I think I > can say that this is the first collection package available for D2. I > still hold hope that it will be used as the standard collection package > for phobos for D2. > > Please visit http://www.dsource.org/projects/dcollections for details. > > Some VERY IMPORTANT notes for this release: > > 1. it is very beta software. Although the implementation has changed very > little from the 1.0 version, not everything will properly compile. I have > filed several compiler bugs to fix some problems I had while porting, and > inserted workarounds for things I could work around. Please use the > LATEST compiler (currently 2.046) because some very important features > have been added that dcollections relies on. Although it is beta, the > algorithms and implementation is largely unchanged so functionality should > be pretty solid. > > 2. the docs are not online for d2. Unfortunately, dsource's > auto-doc-generator that I was using for the 1.0 version is based on a 1.0 > compiler, so it will not automatically generate the d2 docs. However, I > have included some basic ddoc generated docs in the download package, > don't expect them to be very fun to use :) > > 3. The docs are not fully updated, so they might be just flat out wrong! > I plan to update the docs completely for the next beta release. > > So, for the good stuff... here are some notes for differences between 1.0 > and 2.0: > > * Ranges! > * Filled out slicing for all containers > * Cursors are now non-movable. Use ranges for safe iteration. > * The interfaces have been cut down significantly. The question I > asked myself when deciding whether I wanted to keep an interface is "would > anyone use this interface?" > * Functions that should be fast but can be slow (O(n)) have been > removed from all interfaces, and in most cases, from the containers. > Notably missing is searching a non-quick lookup container for a value. Use > std.algorithm.find for that. > * ArrayMultiset has been removed -- it's complexity functions did not > fit with the multiset requirements (specifically, quick lookup of an > element's presence). > * ArrayList slicing now simply returns a range instead of a "live" > slice. Note that an ArrayList range is aliased to a D array. > * Full unit tests added for all container types. > > I have also changed the license from BSD to Boost. > > > > > I have also formally released version 0.03 as version 1.0, nothing has > changed there, including the license. However, no new features will be > added to dcollections version 1.0, only bug fixes will be done. > > Please, file tickets on dsource for any problems you have. And let me > know if there are any ideas you think would be useful. > > -Steve Well as long as you're here can I submit an error here? :) I get an error while building the D2 branch: Error: ArrayMultiset.obj : No such file or directory It seems the ArrayMultiset.d is not in the dcollections folder for the D2.x branch, although it is in trunk (I guess the trunk is the D1.x one?). Is that module deprecated for d2.x? (although it's listed in the win32 batch file)
Re: dcollections 1.0 and 2.0a beta released
Ellery Newcomer Wrote:
> On 05/19/2010 03:07 PM, Steven Schveighoffer wrote:
> > I haven't the slightest what a bimap is :) I am not an expert in
> > collections or data structures, I just reimplement things I have
> > understood. My implementations are basically copied from my algorithm
> > book, and refined as much as I can do.
>
> I think boost.bimap is where I saw it, though I don't don't use c++.
>
> I think it's a map, with values->keys is also a map
That sounds interesting, it might be doable like this:
interface Bimap(K, V) : Map(K, V), Map(V, K)
I'll have a look at it some time.
>
> I have a simple child/sibling tree implementation which I could probably
> dust off and polish up if you want it. The method for visiting the
> elements is kind of weird, though. And I don't know that it exactly fits
> the mold of a reference container. Maybe with cursors.
With opApply, you should have few restrictions on iteration. Technically,
cursors are optional since they are part of the concrete class, but it probably
wouldn't make it into dcollections proper without them.
>
> Ugh, I just noticed LinkList doesn't work with interfaces.
You mean
interface I {}
auto list = new LinkList!I;
??
Please file a ticket w/ test case, it should work.
-Steve
Re: dcollections 1.0 and 2.0a beta released
On 05/19/2010 11:09 AM, Steven Schveighoffer wrote:
After much work and toil, I have created dcollections for D2.
Awesome! I'm looking through it, unfortunately after wandering in the
trunk for a while (I was like, wait, what?). But that was after all good
because I saw a lot of awesome improvements in the new library. This is
solid work.
I salute your decision to frame complexity as a feature and remove
functions with "undecided complexity". This is huge.
That being said, I think dcollections2 has not yet solved a number of
problems, some minor, some annoying, and some fundamental. This makes
things quite unpleasant because, willingly or not, I'm in a three-way
conflict of interest: (1) I can influence to some extent the decision of
adopting dcollections2 for phobos; (2) I have my own design in mind
which is competing with dcollections2; (3) my time is scarce so I'm
having difficulty executing on that design, whereas dcollections2 is
already usable.
I'm not sure where this leaves us. I'm tempted to post a list of
"grievances" with the current design, but it's difficult to make that
sound sincere due to the conflict of interest. Let me start by asking
this: on a scale of 0 ("no change") to 10 ("redesign the whole thing"),
where do you stand regarding the perspective of operating changes to
dcollections2?
Andrei
Re: dcollections 1.0 and 2.0a beta released
Andrej Mitrovic Wrote: > Well as long as you're here can I submit an error here? :) > > I get an error while building the D2 branch: > > Error: ArrayMultiset.obj : No such file or directory Crud, I admit that I assumed anything that built on Linux would build on Windows. I still believe it will, but of course, I need to change the batch file :) > > It seems the ArrayMultiset.d is not in the dcollections folder for the D2.x > branch, although it is in trunk (I guess the trunk is the D1.x one?). Yes, D1 is trunk, D2 is going to eventually be trunk > > Is that module deprecated for d2.x? (although it's listed in the win32 batch > file) Yes, just remove it. I'll fix it when I get a chance. -Steve
Re: dcollections 1.0 and 2.0a beta released
Andrei Alexandrescu Wrote:
> On 05/19/2010 11:09 AM, Steven Schveighoffer wrote:
> > After much work and toil, I have created dcollections for D2.
>
> Awesome! I'm looking through it, unfortunately after wandering in the
> trunk for a while (I was like, wait, what?). But that was after all good
> because I saw a lot of awesome improvements in the new library. This is
> solid work.
Yeah, I will move the D1 version to a branch and copy the D2 to trunk when I
get a chance, Part of the reason is the automatic doc generator will puke if
the trunk is D2.
> That being said, I think dcollections2 has not yet solved a number of
> problems, some minor, some annoying, and some fundamental. This makes
> things quite unpleasant because, willingly or not, I'm in a three-way
> conflict of interest: (1) I can influence to some extent the decision of
> adopting dcollections2 for phobos; (2) I have my own design in mind
> which is competing with dcollections2; (3) my time is scarce so I'm
> having difficulty executing on that design, whereas dcollections2 is
> already usable.
>
> I'm not sure where this leaves us. I'm tempted to post a list of
> "grievances" with the current design, but it's difficult to make that
> sound sincere due to the conflict of interest. Let me start by asking
> this: on a scale of 0 ("no change") to 10 ("redesign the whole thing"),
> where do you stand regarding the perspective of operating changes to
> dcollections2?
It depends on what you want to change. If you say cursors have to go, then I
would say no. If you think some functions/classes need to be renamed, or the
module structure needs to be changed, I'd say fine.
There are other design decisions that can be changed, but I look at it from the
perspective of usefulness to me :) If it stops being useful to me, or does not
provide a feature I want, then I'll not use it, and then I won't want to
maintain it.
I guess start with the big ones, 'cause minor ones aren't likely to be a
problem.
-Steve
Re: dcollections 1.0 and 2.0a beta released
On 05/19/2010 04:37 PM, Steven Schveighoffer wrote:
Andrei Alexandrescu Wrote:
I'm not sure where this leaves us. I'm tempted to post a list of
"grievances" with the current design, but it's difficult to make
Let me start by
asking this: on a scale of 0 ("no change") to 10 ("redesign the
whole thing"), where do you stand regarding the perspective of
operating changes to dcollections2?
It depends on what you want to change. If you say cursors have to
go, then I would say no. If you think some functions/classes need to
be renamed, or the module structure needs to be changed, I'd say
fine.
There are other design decisions that can be changed, but I look at
it from the perspective of usefulness to me :) If it stops being
useful to me, or does not provide a feature I want, then I'll not use
it, and then I won't want to maintain it.
I guess start with the big ones, 'cause minor ones aren't likely to
be a problem.
Well the thing is I'm strongly questioning the whole point of defining a
hierarchy for containers, in particular when the interfaces are
numerous. I'd go as heretical as saying "Container hierarchy are for
languages that suck." Also, the fact that (for efficiency reasons)
ranges are concrete and inaccessible from the abstract interfaces
aggravates the matter even more, to the point where containers are
neither horses nor mules: if you use the interfaces you have only
severely emasculated access to the container's elements, and if you use
the concrete classes why the heck bother with hierarchies in the first
place.
Whew. Let me explain; there's a lot to explain.
Right now there are 10 interfaces in 7 files in the /model/ subdir. It
happens quite often that a given class inherits more than one interface,
for example ArrayList inherits two, and many set types inherit Set which
in turn inherits Addable!V, Iterator!V, Purgeable!V.
The problem with this setup that encodes capabilities in interfaces is
that many sensible combinations of capabilities are impossible to
obtain. Say you want to define a function messWith(C) where C is
Purgeable and Addable. There's no type for that! Set has too many
capabilities (which not all containers might support), so you'll need to
do a runtime check:
void messWith(Addable!int ia) {
auto ip = cast(Purgeable!int) ia;
enforce(ip, "Wrong type etc.");
...
}
It would be more expressive if such capability constraints could be
expressed during compilation.
To see more about this problem, you may want to check "Compound types
for Java" by Buechi and Wech (just google it). The paper explains the
problem in detail and proposes a Java language change to fix it. Java
didn't change and was not able to devise a library solution.
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 ...
}
The inspiration for this approach was given by Scott Meyers' article
"Red code, green code". The approach does work and rather beautifully,
but it's impractical: the class hierarchy forms a dense DAG and if you
add 4-5 capabilities an empty object already has size 8KB consisting
only of routing vtables.
Escalating this discussion one step further (and probably a bit outside
the area of commonly-accepted lore), let me hypothesize that maybe the
entire idea of container hierarchies is a red herring, the hoax of the
1990s. Hierarchies are for types that have a lot of commonality and a
little variability. Containers are not that. They have personality,
refuse to accept straitjacket interfaces, and each has unique
capabilities - as your capability-based design witnesses.
I agree that reuse via binary interfaces is good when you write
functions that exploit them, but in D it's simple and cheap enough to
write a concept-checked generic function to get around that. In my
designs I either know what container I'm dealing with, or I am in
generic-land. I never was like, "mmm, great, I can change this container
type at runtime".
But wait, there's less. Furthermore, container hierarchies encourage
design by inheritance, which is more often than not poor. If you want to
define a container that notifies an observer whenever you add stuff to
it, composition is the best to follow. You don't want a horse with a
violing grafted on its back; keep the horse a horse and play the violin
and it'll dance.
I've never, ever been in a place in life when I thought, "I should
derive from this container class and hook a method of it." Composition
always wins.
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 foster a federation of independent
containers abiding to identical names for similar functionality. Then a
few concept checks (a
Re: dcollections 1.0 and 2.0a beta released
On 05/19/2010 03:55 PM, Steven Schveighoffer wrote:
Ellery Newcomer Wrote:
I have a simple child/sibling tree implementation which I could probably
dust off and polish up if you want it. The method for visiting the
elements is kind of weird, though. And I don't know that it exactly fits
the mold of a reference container. Maybe with cursors.
With opApply, you should have few restrictions on iteration. Technically,
cursors are optional since they are part of the concrete class, but it probably
wouldn't make it into dcollections proper without them.
When I was using it, it was usually more than an iteration that I found
I needed. I think I had preorder traversals and postorder traversals
with the ability to define actions at parent -> child, child -> sibling,
and child -> parent transitions, access to the stack and some of the
history of what had been visited. On the whole, it required heavy
exposure of the structure of the tree. A wrapper around the tree nodes
doesn't make a lot of sense, and if you don't have a wrapper, cursors
don't really make a lot of sense either.
Random thought: wouldn't a child/sibling tree be a good base for
implementing tries?
Ugh, I just noticed LinkList doesn't work with interfaces.
You mean
interface I {}
auto list = new LinkList!I;
??
Please file a ticket w/ test case, it should work.
-Steve
indeed it should, but D doesn't like you :)
http://www.dsource.org/projects/dcollections/ticket/4
Re: dcollections 1.0 and 2.0a beta released
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 your ideas the people that like them can switch to using your collections. Bye, bearophile
Bartosz' Message Passing talk tonight
Title: The Anatomy of Message Passing Speaker: Bartosz Milewski Date: May 19, 2010 Time: 7 pm Place: Microsoft Eastside Campus, Bldg 41, Townsend (see our website www.nwcpp.org for directions).
Re: dcollections 1.0 and 2.0a beta released
While I haven't read dcollections yet, I definitely agree with you about not liking container hierarchies, and about the importance of support for ranges. I hope Steven can be convinced that this is a good way to go :-).
Re: dcollections 1.0 and 2.0a beta released
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 easily express what capabilities > a given client function needs from a container. > > Destroy me :o). So instead of STL's concept hierarchy, you have essentially concept tags. Very Web 2.0. :-) I agree that there doesn't seem to be any coding benefit to STL's concepts being hierarchical. If you need a push_back(), you've got to check for push_back(). The main benefit seems to be for documentation purposes, allowing you to say things like "bidirectional_iterator has this and that, plus everything in forward_iterator". But that could easily be rephrased as "it has backward_iteration plus forward_iteration" with two pages describing those two tags. So I like the sound of it. But it seems actually a pretty small departure from the STL approach, in practice. --bb
Re: dcollections 1.0 and 2.0a beta released
Oooohhh goody goody goody! n_n I'm in the process of making a little toy project ATM. I'll shall integrate dcollections 2.0a into ASAP.
Re: dcollections 1.0 and 2.0a beta released
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 foster a federation of independent > containers abiding to identical names for similar functionality. Then a > few concept checks (a la std.range checks) can easily express what > capabilities a given client function needs from a container. This might have a simple answer. Dcollections implementations are not a hierarchy, just the interfaces are. I.e. there aren't many kinds of HashMaps that derive from each other. But the interfaces are not detrimental to your ideas. The only thing interfaces require is that the entities implementing them are classes and not structs. As long as you agree that classes are the right call, then interfaces can co-exist with your other suggestions without interference. Yes, if you want to define "this function needs something that is both addable and purgeable, I don't have an interface for that. But a concept can certainly define that generically (which is what you want anyways), or you could just say "I need a List" and get those functions also. It also does not force entities other than dcollections objects to be classes, they could be structs and implement the correct concepts. 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 with dynamic libraries that a library exposes some piece of itself as a Map or List interface. So my answer is -- go ahead and define these concepts and required names, and you can ignore the interfaces if they don't interest you. They do not subtract from the possibilities, and others may find good use for them. Does that make sense? -Steve
Re: dcollections 1.0 and 2.0a beta released
Graham St Jack Wrote: > While I haven't read dcollections yet, I definitely agree with you about > not liking container hierarchies, and about the importance of support for > ranges. > > I hope Steven can be convinced that this is a good way to go :-). All dcollections classes support ranges. I am already convinced of that :) -Steve
Re: dcollections 1.0 and 2.0a beta released
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 having an interface prevents someone from using a concept on the concrete class. > People can use the dcollections in the following weeks and months, and when > you have implemented your ideas the people that like them can switch to using > your collections. If it's at all possible, I'd like to cooperate on making dcollections phobos-qualified. So I'm glad to try and find a way to satisfy Andrei's concerns. -Steve
Re: dcollections 1.0 and 2.0a beta released
Steven Schveighoffer: > If it's at all possible, I'd like to cooperate on making dcollections > phobos-qualified. So I'm glad to try and find a way to satisfy Andrei's > concerns. Very good. Sometimes I am a too much pessimistic person :-) Bye, bearophile
Re: dcollections 1.0 and 2.0a beta released
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 and purge ...
}
Are you sure this is necessary? I'm wondering how the above is different from:
void messWith(C)(C i) if (IsAddable!C && IsPurgeable!C) {
... use i's capabilities to add and purge
}
where IsAddable just checks for an 'add' function and IsPurgeable
checks for a 'purge' function. Obviously, one is a template and the
other isn't. I'd expect the template function to be more performant
since it doesn't require an indirection to call into the container. Is
the need for runtime-swappable containers really common enough to
justify adding it to the standard library? Won't adding this encourage
people to use it without realizing the downside in performance and
failed optimization opportunities because of the hidden dynamic
dispatch? It's a quite nice idea, but I don't like the tradeoff.
This criticism is valid for containers implementing interfaces too. In
my first Java programs, I was always declaring variables as the List
interface, then instantiating an ArrayList for them, thinking it'd make
things more generic and easier to change later. Generic sometime is
good, but if you do that with containers in D you're in for an
important performance drop. Personally, I'd scrap anything that's not
made of static calls (final functions in a class are fine) so people
can't easily make these kind of mistakes (and then believe D is slow).
Also, addable and purgeable above being or'ed constants makes the
system difficult to scale to new concepts. The template predicates on
the other hand are infinitely extendable: if my containers have
'commit' and 'rollback' functions, I can define IsTransactional to
check for the presence of the functions and make some algorithms that
benefits from this. In fact, this can apply to anything, not just
containers. Range are already using this pattern. Wouldn't it make
things easier to learn if we could just reuse the same principle with
containers?
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: dcollections 1.0 and 2.0a beta released
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 an climactic disharmony. 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 easily express what capabilities a given client function needs from a container. This might have a simple answer. Dcollections implementations are not a hierarchy, just the interfaces are. I.e. there aren't many kinds of HashMaps that derive from each other. But the interfaces are not detrimental to your ideas. The only thing interfaces require is that the entities implementing them are classes and not structs. As long as you agree that classes are the right call, then interfaces can co-exist with your other suggestions without interference. Yes, if you want to define "this function needs something that is both addable and purgeable, I don't have an interface for that. But a concept can certainly define that generically (which is what you want anyways), or you could just say "I need a List" and get those functions also. It also does not force entities other than dcollections objects to be classes, they could be structs and implement the correct concepts. 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 with dynamic libraries that a library exposes some piece of itself as a Map or List interface. So my answer is -- go ahead and define these concepts and required names, and you can ignore the interfaces if they don't interest you. They do not subtract from the possibilities, and others may find good use for them. 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 comprehension needed to understand and use the library. (See Tangled up in tools http://www.pragprog.com/magazines/2010-04/tangled-up-in-tools) Second, I think designing a library to be flexible enough to meet some future, anticipated need (e.g. dlls) is a good idea, but actually implementing vaporous future needs is fraught with peril; it's too easy to guess wrong. Third, interface base design is viral; If library X uses interfaces then I have to use interfaces to interface with it. And if another library Y uses classes, then I'm going have to write a (needless) wrapper around one of them.
Re: Bartosz' Message Passing talk tonight
I wish it was announced more that half an hour ahead of time. I would have gone, but I just saw this. On Wed, 19 May 2010 18:31:53 -0600, Walter Bright wrote: Title: The Anatomy of Message Passing Speaker: Bartosz Milewski Date: May 19, 2010 Time: 7 pm Place: Microsoft Eastside Campus, Bldg 41, Townsend (see our website www.nwcpp.org for directions). -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Bartosz' Message Passing talk tonight
On Wed, 19 May 2010 22:28:26 -0600, Phil Deets wrote: On Wed, 19 May 2010 18:31:53 -0600, Walter Bright wrote: Title: The Anatomy of Message Passing Speaker: Bartosz Milewski Date: May 19, 2010 Time: 7 pm Place: Microsoft Eastside Campus, Bldg 41, Townsend (see our website www.nwcpp.org for directions). I wish it was announced more that half an hour ahead of time. I would have gone, but I just saw this. I see there is a newsfeed on nwcpp.org which I've now subscribed to. I should be able to make it to future meetings as long as they are posted ahead of time to the feed. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: dcollections 1.0 and 2.0a beta released
On 20/05/10 13:39, Bernard Helyer wrote: Oooohhh goody goody goody! n_n I'm in the process of making a little toy project ATM. I'll shall integrate dcollections 2.0a into ASAP. ArrayList doesn't compile with warnings as it overrides opEquals, but doesn't mark it as such.
Re: dcollections 1.0 and 2.0a beta released
On 20/05/10 18:11, Bernard Helyer wrote: On 20/05/10 13:39, Bernard Helyer wrote: Oooohhh goody goody goody! n_n I'm in the process of making a little toy project ATM. I'll shall integrate dcollections 2.0a into ASAP. ArrayList doesn't compile with warnings as it overrides opEquals, but doesn't mark it as such. And lines 772 and 780 complained about not being able to implicitly cast const(Thing) to Thing. Which is strange, because T was Thing. Inserting cast(Thing) seemed to 'fix' it. D=
Re: dcollections 1.0 and 2.0a beta released
On 20/05/10 18:16, Bernard Helyer wrote: On 20/05/10 18:11, Bernard Helyer wrote: On 20/05/10 13:39, Bernard Helyer wrote: Oooohhh goody goody goody! n_n I'm in the process of making a little toy project ATM. I'll shall integrate dcollections 2.0a into ASAP. ArrayList doesn't compile with warnings as it overrides opEquals, but doesn't mark it as such. And lines 772 and 780 complained about not being able to implicitly cast const(Thing) to Thing. Which is strange, because T was Thing. Inserting cast(Thing) seemed to 'fix' it. D= Sorry about the blow by blow, but the cursor thing seems to work well in my situation. Me likey dcollections very much so far. Go Steve!
