After learning and using D for a little while I have discovered some (in my opinion) problems with the slices and associative array built-ins (for now I will just say slice).  The main issue I have is that there is no way to pass around something that looks like and acts like a slice.  This is because there is no class or interface to which slices adhere.  I think this is a very simple concept and it could be easily remedied by creating an Array interface which slices implement.  This way you could create things like lazy and asynchronously filled arrays.

I have to admit that I am a little at a loss for examples where a slice could be used this way but I would like to have the power because that is the heart of polymorphism.  I could design a class/function/... that takes an "object that implements Array" and if later I find out that I would like to pass a slightly different array I could do that without any changes to my code.  An example of this is an old issue from C++.  RapidXML (you guessed it, an XML library) was initially only able to read from a file. This means that if you were doing something (like a webserver application) you would have to write the incoming XML to disk before parsing it, losing all of the speed on RapidXML.  The thing was that this design choice was because it was a lot of work to support both efficiently and requiring strings as input meant that most users would have to load a whole file into memory before starting the parsing process.  If we were to write DXML we could instead require an input that is an array of characters and we could pass in either a string or a file (or file reader, or whatever) that read more of the file as it was accessed.  (of course doing some nice buffering and the like)  This is because all DXML wants is a bunch of characters, it doesn't care where they are coming from.

An example for AAs is if you want to do something like live translation in your app.  It makes sense to have an AA of strings for every language. But, if every language is not complete you end up with holes.  Instead you decide you wish to fallback to a complete language.  Now, you have to rewrite your app so that every function that displays stuff to the User takes both the locale and the fallback.  Or, you create an AA class that handles lookup for you.  But you still can't pass this around because your program is wired for AAs.

In, conclusion. (Tl:Dr) slices and AAs do not allow polymorphism and therefore are decreasing the power and flexibility of D.

I hope to hear your opinions,
Kevin.

On Friday, 2 March 2012 at 13:33:17 UTC, Kevin Cox wrote:
> After learning and using D for a little while I have discovered some (in my
> opinion) problems with the slices and associative array built-ins (for now
> I will just say slice).  The main issue I have is that there is no way to
> pass around something that looks like and acts like a slice.  This is
> because there is no class or interface to which slices adhere.  I think
> this is a very simple concept and it could be easily remedied by creating
> an Array interface which slices implement.  This way you could create
> things like lazy and asynchronously filled arrays.
> [...]
> In, conclusion. (Tl:Dr) slices and AAs do not allow polymorphism and
> therefore are decreasing the power and flexibility of D.
>
> I hope to hear your opinions,
> Kevin.

D is not purely object oriented and must provide primitives the meet or exceed C.

The style for D code also tends to templates and meta programming. Ranges[1] fit nicely to this and the idea of slicing.

1. http://dlang.org/phobos/std_range.html

hmm bed time, no time for long explanations.

On 03/02/2012 06:03 AM, Jesse Phillips wrote:
> On Friday, 2 March 2012 at 13:33:17 UTC, Kevin Cox wrote:
>> After learning and using D for a little while I have discovered some
>> (in my
>> opinion) problems with the slices and associative array built-ins (for
>> now
>> I will just say slice). The main issue I have is that there is no way to
>> pass around something that looks like and acts like a slice. This is
>> because there is no class or interface to which slices adhere. I think
>> this is a very simple concept and it could be easily remedied by creating
>> an Array interface which slices implement. This way you could create
>> things like lazy and asynchronously filled arrays.
>> [...]
>> In, conclusion. (Tl:Dr) slices and AAs do not allow polymorphism and
>> therefore are decreasing the power and flexibility of D.

inputRangeObject() and outputRangeObject() functions return polymorphic interfaces in the form of InputRangeObject and OutputRangeObject.

>>
>> I hope to hear your opinions,
>> Kevin.
>
> D is not purely object oriented and must provide primitives the meet or
> exceed C.
>
> The style for D code also tends to templates and meta programming.
> Ranges[1] fit nicely to this and the idea of slicing.
>
> 1. http://dlang.org/phobos/std_range.html
>
> hmm bed time, no time for long explanations.

A shameless plug of a tutorial of mine:

  http://ddili.org/ders/d.en/ranges.html

That includes the following link to Andrei's paper:

  http://www.informit.com/articles/printerfriendly.aspx?p=1407357

Ali

On 3/2/12 7:33 AM, Kevin Cox wrote:
[snip]
> In, conclusion. (Tl:Dr) slices and AAs do not allow polymorphism and
> therefore are decreasing the power and flexibility of D.

Slices are primitive, concrete components that are close to the metal and are best for implementing abstractions, not defining them. You can always build and use abstract interfaces (that may or may not use slices internally). But at a point the turtles must end, and that's where the slices are.

Andrei

On Mar 2, 2012 10:30 AM, "Andrei Alexandrescu" < SeeWebsiteForEmail@erdani.org> wrote
>
> Slices are primitive, concrete components that are close to the metal and
are best for implementing abstractions, not defining them. You can always build and use abstract interfaces (that may or may not use slices internally). But at a point the turtles must end, and that's where the slices are.
>
> Andrei
>

Thanks for all of the replies.  I will read up and see what I think.

Although if slices are still built-in but act as if they are part of an interface will that slow them down?  And, if so where is the slowdown?  Is it in the interfaces?

-Kevin

On 3/2/12 10:24 AM, Kevin Cox wrote:
> Although if slices are still built-in but act as if they are part of an
> interface will that slow them down?  And, if so where is the slowdown?
> Is it in the interfaces?

Yes, a traditional interface (in the sense I gather you use it) uses indirection by definition, meaning the user has access to a reference, which points to a table of primitive functions that in turn are implemented by various concrete implementers. The scheme requires dynamic allocation not only of the data, but of the concrete objects managing it as well.

In contrast, a slice is simply a pair: a pointer to the data and the extent of the data. Accessing a slice is as direct as indexing the pointer after a bounds check.


Andrei

On 03/02/2012 09:03 AM, Jesse Phillips wrote:
> D is not purely object oriented and must provide primitives the meet or exceed C.
>
> The style for D code also tends to templates and meta programming. Ranges[1] fit nicely to this and the idea of slicing.
>
> 1. http://dlang.org/phobos/std_range.html
>
> hmm bed time, no time for long explanations.
Is there something on ranges that is more of a write-up.  Something to explain purpose, implementation, usage, ...?  Or if not some code that makes good use of ranges?

Thanks, Kevin

On Saturday, 3 March 2012 at 05:00:53 UTC, Kevin wrote:
> Is there something on ranges that is more of a write-up.  Something to explain purpose, implementation, usage, ...?  Or if not some code that makes good use of ranges?
>
> Thanks, Kevin

http://ddili.org/ders/d.en/ranges.html

On Sat, Mar 3, 2012 at 12:09 AM, Xinok <xinok@live.com> wrote:

> http://ddili.org/ders/d.en/**ranges.html<http://ddili.org/ders/d.en/ranges.html>
>

Thanks for the great link.

And thanks everyone for your help.  I can't believe I missed ranges as they are exactly what I wanted.

Kevin