On 12/15/12 7:15 PM, Patrick Walton wrote:
However, if you modify the algorithm to use unique pointers throughout,
then your methods like get() can probably return a borrowed pointer
instead.
To add: For anyone interested in making data structures that don't use
the garbage collector, look at
On 12/15/12 4:38 PM, Steve Jenson wrote:
I could use advice here. Is it possible for me to write a single trait
that can be used by both users that want to use managed boxes and people
who wish otherwise? IOW, what is the best way to abstract away the @sign
in this trait?
It depends on how you
On Sat, Dec 15, 2012 at 4:45 PM, Steve Jenson wrote:
>
>
>
> On Sat, Dec 15, 2012 at 8:58 AM, Benjamin Striegel
> wrote:
>>
>> Would this trait:
>>
>> pub trait Map {
>> pure fn get(k: K) -> @Option;
>> pure fn put(k: K, v: V) -> self;
>> pure fn delete(k: K) -> self;
>>
On Sat, Dec 15, 2012 at 8:58 AM, Benjamin Striegel
wrote:
> Would this trait:
>
> pub trait Map {
> pure fn get(k: K) -> @Option;
> pure fn put(k: K, v: V) -> self;
> pure fn delete(k: K) -> self;
> pure fn traverse(f: fn((&K), (@Option)));
> }
>
> be something that
On Sat, Dec 15, 2012 at 11:46 AM, Patrick Walton wrote:
> On 12/15/12 8:58 AM, Benjamin Striegel wrote:
>
>> Would this trait:
>>
>> pub trait Map {
>>pure fn get(k: K) -> @Option;
>>pure fn put(k: K, v: V) -> self;
>>pure fn delete(k: K) -> self;
>>pure fn tra
On 12/15/12 8:58 AM, Benjamin Striegel wrote:
Would this trait:
pub trait Map {
pure fn get(k: K) -> @Option;
pure fn put(k: K, v: V) -> self;
pure fn delete(k: K) -> self;
pure fn traverse(f: fn((&K), (@Option)));
}
be something that ought to live somewher
Would this trait:
pub trait Map {
pure fn get(k: K) -> @Option;
pure fn put(k: K, v: V) -> self;
pure fn delete(k: K) -> self;
pure fn traverse(f: fn((&K), (@Option)));
}
be something that ought to live somewhere in the standard library?
I also see that you have a
