On Friday, 4 September 2015 at 23:15:54 UTC, Andrei Alexandrescu wrote:
> [...]
> My thinking is that significant work in this(this) is poor D style. Eager copying for containers doesn't seem like the best way to go. -- Andrei

I feel should add that I still very much favor simple value type containers.

C++ does just fine with value-type containers. I know "D isn't C++" but if it works, it works. I think the D community often tries way too hard to be innovative, and in many cases, less is more. WYSIWYG is a much more important principal to me than whatever resulted in a RefCounted(T) that likes to dress up like a value type. Structs doing heavy work in this(this) may be bad D style, but structs that don't act like structs is worse.

On 05-Sep-2015 05:36, bitwise wrote:
> On Friday, 4 September 2015 at 23:15:54 UTC, Andrei Alexandrescu wrote:
>> [...]
>> My thinking is that significant work in this(this) is poor D style.
>> Eager copying for containers doesn't seem like the best way to go. --
>> Andrei
>
> I feel should add that I still very much favor simple value type
> containers.
>
> C++ does just fine with value-type containers. I know "D isn't C++" but
> if it works, it works.

I agree if only on the grounds of composability. Value-typed containers are "more" then ref-based ones. As we can always get:

Unqiue!ValueTypedContainer or RC!ValueTypedContainer

on top of value type container.

> I think the D community often tries way too hard
> to be innovative, and in many cases, less is more. WYSIWYG is a much
> more important principal to me than whatever resulted in a RefCounted(T)
> that likes to dress up like a value type. Structs doing heavy work in
> this(this) may be bad D style, but structs that don't act like structs
> is worse.
>


-- 
Dmitry Olshansky

On Fri, 2015-09-04 at 22:21 +0000, bitwise via Digitalmars-d wrote:
> 
[…]
> This is another problem:
>    "Containers do not form a class hierarchy, instead they
> implement a common set of primitives (see table below). These
> primitives each guarantee a specific worst case complexity and
> thus allow generic code to be written independently of the
> container implementation."
> 
> I believe this is wrong, in that the point of abstraction should be the Ranges you get from the containers, not the containers themselves. I think it's a little silly for an Array(T) to have a "removeAny()" method.
> 
> 
[…]

I think I am missing a step in the argument here: if the point is that Ranges are the core of the abstraction, why does there need to be a class inheritance hierarchy. The lessons from C++, Java, Python, and Go, include that the obsession with inheritance during the 1990s went far too far. Inheritance can be useful, but for frameworks it is only conformance to interfaces that matters for consistency across the framework. Thus as long as every data structure type conforms to the correct interface so that there is composability in the use of Ranges, then things are fine.

This though is philosophy and far too general. To continue this aspect of the debate we would need to deal in more specific things. Are there some examples from Phobos and your containers that we could pin this on?


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday, 5 September 2015 at 06:44:30 UTC, Dmitry Olshansky wrote:
> On 05-Sep-2015 05:36, bitwise wrote:
>> On Friday, 4 September 2015 at 23:15:54 UTC, Andrei Alexandrescu wrote:
>>> [...]
>> I feel should add that I still very much favor simple value type
>> containers.
>>
>> C++ does just fine with value-type containers. I know "D isn't C++" but
>> if it works, it works.
>> [...]
>
> I agree if only on the grounds of composability. Value-typed containers are "more" then ref-based ones. As we can always get:
>
> Unqiue!ValueTypedContainer or RC!ValueTypedContainer
>
> on top of value type container.
>

or even a class! =)

static import collections;
final class List(T) {
    private collections.List!T _list;
    alias _list this;

    this(Args...)(Args args) {
        _list = collections.List!T(args);
    }
}

On Saturday, 5 September 2015 at 06:59:28 UTC, Russel Winder wrote:
> On Fri, 2015-09-04 at 22:21 +0000, bitwise via Digitalmars-d wrote:
>> This is another problem:
>>
>> --->FROM THE D DOCS
>>>    "Containers do not form a class hierarchy, instead they
>>> implement a common set of primitives (see table below). These
>>> primitives each guarantee a specific worst case complexity and
>>> thus allow generic code to be written independently of the
>>> container implementation."
>> 
>> I believe this is wrong, in that the point of abstraction should be the Ranges you get from the containers, not the containers themselves. I think it's a little silly for an Array(T) to have a "removeAny()" method.
>> 
>> 
>
> I think I am missing a step in the argument here:

Sorry.. I'm not sure if this is the source of confusion, but I was actually quoting the D documentation there. I've modified my message to make the quote more visible. That quote doesn't represent a point I agree with, but rather a point I'm trying to shoot down.

> if the point is that Ranges are the core of the abstraction, why
> does there need to be a class inheritance hierarchy.The lessons
> from C++, Java, Python, and Go, include that the obsession with inheritance during the 1990s went far too far. Inheritance can be useful, but for frameworks it is only conformance to interfaces that matters for consistency across the framework. Thus as long as every data structure type conforms to the correct interface so that there is composability in the use of Ranges, then things are fine.

I am saying that there should _not_ be a class hierarchy. Currently, there is no class hierarchy, but if you read that section I quoted from the container specification, it says that all containers should follow a pattern which allows algorithms to work on any container indiscriminately, which basically has the same effect as if all containers were forced to inherit the same interface. I believe this is over-generalization, and that the abstraction point should be backed-up to ranges. Trying to make a multi-map have the same interface as a vector or array, so that algorithms can be made to work on all containers indiscriminately, is a pipe dream. It's much more reasonable to expect algorithms to be able to work on any range, regardless of which container it has come from.

> This though is philosophy and far too general. To continue this aspect of the debate we would need to deal in more specific things. Are there some examples from Phobos and your containers that we could pin this on?

With the containers I've built, I try to add overloads that take a ranges wherever possible(pushBack, push, insert, find, etc..).

The difference between my approach and the one suggested by the current container spec is that the spec would force me to name "pushBack" and "push" the same thing, even though the first one was a member function of a list/array/vector, and the second one was a member of a stack. Containers may turn out to have similar interfaces, but it's not a reason to rigidly define an interface to which all containers must adhere.

  Bit

On Saturday, 5 September 2015 at 00:21:42 UTC, Timon Gehr wrote:
> On 09/05/2015 01:15 AM, Andrei Alexandrescu wrote:
>> My thinking is that significant work in this(this) is poor D style.
>> Eager copying for containers doesn't seem like the best way to go. --
>> Andrei
>
> @disable this(this) for ephemeral containers?

I actually missed this message somehow, but this is what I'll do. A move-only container(base container) is fine by me. It'll probably end up sitting in a class, or the global scope anyways. Passing them around arbitrarily and joining them with "~" was not part of the plan.

Finally, I can throw in one of these, and everybody wins:
alias ListRef(T) = RefCounted!(List!T);

   Bit