www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.container update - now Array is in

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://erdani.com/d/phobos/std_container.html
http://erdani.com/d/phobos/container.d

I defined Array as a straightforward implementation of the homonym 
abstraction. There are a few imperfect corners, but by and large I'm 
starting to believe it's becoming possible to write certain 
cross-container codes.


Andrei
May 27 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-05-27 21:08:29 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 
 http://erdani.com/d/phobos/std_container.html
 http://erdani.com/d/phobos/container.d
 
 I defined Array as a straightforward implementation of the homonym 
 abstraction. There are a few imperfect corners, but by and large I'm 
 starting to believe it's becoming possible to write certain 
 cross-container codes.


I don't get that:

	 property void reserve(size_t e)

Why is reserve a property? You want it called like that?

	array.reserve = 10;

I'm sure it's just an oversight.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 27 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/27/2010 09:27 PM, Michel Fortin wrote:

 On 2010-05-27 21:08:29 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:


 http://erdani.com/d/phobos/std_container.html
 http://erdani.com/d/phobos/container.d

 I defined Array as a straightforward implementation of the homonym
 abstraction. There are a few imperfect corners, but by and large I'm
 starting to believe it's becoming possible to write certain
 cross-container codes.


 I don't get that:

  property void reserve(size_t e)

 Why is reserve a property? You want it called like that?

 array.reserve = 10;

 I'm sure it's just an oversight.


Sorry, fixed now.

Andrei
May 27 2010
prev sibling next sibling parent Pillsy <pillsbury gmail.com> writes:
== Quote from Andrei Alexandrescu
(SeeWebsiteForEmail erdani.org)'s article:


 I defined Array as a straightforward implementation of the
 homonym abstraction. There are a few imperfect corners, but
 by and large I'm starting to believe it's becoming possible
 to write certain cross-container codes.


I think it might be a good idea is to make it so that, for struct
types, when they're removed from the containers, their destructors
are run[1]. That way containers would be able to work with some
kinds of "smart pointer" abstractions once the compiler is up to
supporting them, which would make both the containers and
the "smart pointers" a good deal more useful.

Cheers,
Pillsy

[1] I asked some questions about the feasibility of this in d.learn.
May 28 2010
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 27 May 2010 21:08:29 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 http://erdani.com/d/phobos/std_container.html
 http://erdani.com/d/phobos/container.d

 I defined Array as a straightforward implementation of the homonym  
 abstraction. There are a few imperfect corners, but by and large I'm  
 starting to believe it's becoming possible to write certain  
 cross-container codes.



I just noticed, there is no doc for ElementType, only ValueType and  
KeyType.

-Steve
May 28 2010
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 28 May 2010 15:51:53 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 On Thu, 27 May 2010 21:08:29 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:


 http://erdani.com/d/phobos/std_container.html
 http://erdani.com/d/phobos/container.d

 I defined Array as a straightforward implementation of the homonym  
 abstraction. There are a few imperfect corners, but by and large I'm  
 starting to believe it's becoming possible to write certain  
 cross-container codes.



 I just noticed, there is no doc for ElementType, only ValueType and  
 KeyType.



Also, ElementType is also a template in std.range, can we change one of  
these?  I would use the following condition to accept a range:


struct container(T)
{

    void add(R)(R r) if (isInputRange!R &&  
isImplicitlyConvertible(ElementType!R, T)
}

But I think if container(T) defines ElementType, the compiler will be  
confused...

-Steve
May 28 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/28/2010 02:51 PM, Steven Schveighoffer wrote:

 On Thu, 27 May 2010 21:08:29 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 http://erdani.com/d/phobos/std_container.html
 http://erdani.com/d/phobos/container.d

 I defined Array as a straightforward implementation of the homonym
 abstraction. There are a few imperfect corners, but by and large I'm
 starting to believe it's becoming possible to write certain
 cross-container codes.



 I just noticed, there is no doc for ElementType, only ValueType and
 KeyType.

 -Steve


I figured out that ElementType is actually unneeded - introspection can 
extract it for you, see std.range.ElementType.

Andrei
May 28 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 28 May 2010 16:03:10 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 05/28/2010 02:51 PM, Steven Schveighoffer wrote:

 On Thu, 27 May 2010 21:08:29 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 http://erdani.com/d/phobos/std_container.html
 http://erdani.com/d/phobos/container.d

 I defined Array as a straightforward implementation of the homonym
 abstraction. There are a few imperfect corners, but by and large I'm
 starting to believe it's becoming possible to write certain
 cross-container codes.



 I just noticed, there is no doc for ElementType, only ValueType and
 KeyType.

 -Steve


 I figured out that ElementType is actually unneeded - introspection can  
 extract it for you, see std.range.ElementType.


Well, the docs still use ElementType everywhere.  I don't really know how  
it would be introspected, what common function are all containers expected  
to implement (analogous to front() in a range)?

The only thing I would suggest is that having ElementType or something  
equivalent, would help with documentation, since ddoc would be immune to  
said introspection.

-Steve
May 28 2010