The demise of T[new]

[Leandro Lucarella]

Andrei Alexandrescu, el 19 de octubre a las 10:18 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 18 de octubre a las 20:16 me escribiste:
> >>Here's what I wrote to Walter:
> >>
> >>====================
> >>I'm going to suggest something terrible - let's get rid of T[new]. I
> >>know it's difficult to throw away work you've already done, but
> >>really things with T[new] start to look like a Pyrrhic victory. Here
> >>are some issues:
> >>
> >>* The abstraction doesn't seem to come off as crisp and clean as we
> >>both wanted;
> >>
> >>* There are efficiency issues, such as the two allocations that you
> >>valiantly tried to eliminate in a subset of cases;
> >>
> >>* Explaining two very similar but subtly different types to
> >>newcomers is excruciatingly difficult (I'll send you a draft of the
> >>chapter - it looks like a burn victim who didn't make it);
> >>
> >>* Furthermore, explaining people when to use one vs. the other is
> >>much more difficult than it seems. On the surface, it goes like
> >>this: "If you need to append stuff, use T[new]. If not, use T[]."
> >>Reality is much more subtle. For one thing, T[new] does not allow
> >>contraction from the left, whereas T[] does. That puts T[] at an
> >>advantage. So if you want to append stuff and also contract from the
> >>left, there's nothing our abstractions can help you with.
> >
> >I think this is getting overcomplicated. I don't see it as complex, I see
> >it like this:
> >
> >2 types should be provided: array and slice.
> >
> >array is a *real* type, storing and owning memory, it should be something
> >like this (conceptually):
> >
> >class array(T)
> >{
> >	size_t length;
> >	size_t capacity;
> >	T[capacity] elements;
> >}
> 
> At the point I introduce arrays I hadn't described classes.

You are talking about the book, right? You don't have to! You can explain
arrays without talking about classes at all! See the Python Tutorial for
example:
http://docs.python.org/tutorial/index.html

You see all kind of complex data structures (lists, dictionaries, tuples,
strings, sets), input and output, and even exceptions! before classes. And
I read it, and was a very easy and pleasant reading.

Talking about a class here was just to prove my point more easily because
I *know* everybody here knows very well about classes semantics. I was not
describing it for a book.

> One major problem with writing a "The X Programming Language" book
> is sequencing. It's very easy to explain a complicated feature if
> the listener knows all others. It is very difficult to introduce
> them serially.

I don't think an array would be the case, come on! =)

> >1) a pure reference type.
> >2) 1 allocation only (interior pointers are not a problem, the GC have to
> >   support them anyways).
> >3) easily appendable (capacity field).
> >
> >slice should be something like this:
> >
> >struct slice(T)
> >{
> >	size_t length;
> >	T* ptr;
> >}
> 
> structs and pointers have also not been introduced yet.

I don't know what this have to do with the book. Should be D designed
based on how good are you to explain the concepts on the book?  I think
this is getting ridiculous... seriously. I don't want to be rude, I know
you're putting a lot of work in the book and we all appreciate that, but
you didn't mention any technical point about what I wrote.

> >I'm missing something? Why this shouldn't work?
> 
> It may work, but I was unable to pull it off reasonably well.

What problems did you find?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
DESCARTAN BIDET VIRTUAL PORQUE NO LAVA
	-- Cronista TV