On Thu, 23 Jul 2009 13:10:59 -0400, Jarrett Billingsley
<jarrett.billingsley@gmail.com> wrote:
> On Thu, Jul 23, 2009 at 12:11 PM, Rainer Deyke<rainerd@eldwood.com>
> wrote:
>
>> Yes, C++ has problems, but these problems can be fixed! The
>> struct/class split, on the other hand, introduces many more problems
>> that are harder to fix.
>
> You know, this is like the first thing C++ users complain about on the
> IRC channel when they find D: "what if I want to turn a class into a
> struct, or vice versa?"
>
> I've been using D for five years, and I have never.
>
> EVER.
>
> Needed or desired to do that. Nor have I heard anyone but new C++
> users complaining about it.
I did.
With dcollections, my nodes were classes at first, because they were
supposed to be heap-allocated reference types.
However, when I realized that with a custom allocator, I could
tremendously increase performance, I had to switch to structs.
What ended up happening is I simply aliased Node to node *, and that was
that. Come to think of it, I probably didn't put enough thought in my
choice of classes to begin with.
This however, is not a true "change" since I just changed classes to
struct references, not to actual value type structs.
I plan on doing some more class-to-struct changes, not sure how it will
pan out.
But I think it certainly does come up that choosing struct or class is not
an easy decision, and both can have advantages/disadvantages.
However, I don't think C++ solves that problem very well either.
The one thing I think is missing from D in this area is struct interfaces.
-Steve

Andrei Alexandrescu wrote:
> Ary Borenszweig wrote:
>> Unfortunately the designers of D doesn't care at all about IDE support
>> for their language, even though in any "why don't you use D"
>> discussion it is mentioned.
>
> The problem is not not caring. For one, I'd love a D IDE as much as the
> next guy, but I don't have the resources to put into writing one. IDEs
> come with language acceptance and are seldom written by the creator of
> the language.
I'm not talking about writing an IDE. I'm talking about when thinking of
a feature, think how this could be supported in an IDE.
For instance properties seem to be a fundamental thing in Delphi and C#.
When you are debugging and you watch some varaible, the debugger
automatically allows you to expand a node and see the varaible's
properties. You can't do that with D because any function that has zero
parameters could be a property, even though some functions aren't
properties.
> By the way, we must be doing something right. As of ten days ago there
> were 30,800 page views for The Case for D, and I just noticed that in
> the past week the presale rate for The D Programming Language has doubled.
Great! :-)

Rainer Deyke wrote:
> 1. C++'s object model, complete with polymorphic value types,
> deterministic destructors, arbitrary copy constructors, and optional
> lack of default constructor. D's structs come close, but I think the
> class/struct split hurts D more than it helps. And, yes, C++ has a lot
> of room for improvement here.
I'm with Andrei in saying that polymorphic value types are a very bad
idea. I've never seen a use case for them that wasn't a mistake.

Andrei Alexandrescu wrote:
> By the way, we must be doing something right. As of ten days ago there
> were 30,800 page views for The Case for D, and I just noticed that in
> the past week the presale rate for The D Programming Language has doubled.
Must be those classicempire affiliate links!!!

Michel Fortin wrote:
> If I'm not mistaken, both your D1 and D2 installer install at the same
> location and they will overwrite each other. I'd much prefer if D2 and
> D1 could coexist without having to go with a special installer or custom
> installation instructions. Otherwise it'll be hard for me to offer the
> choice between D1 and D2 in Xcode (and I certainly do want that choice
> to be available).
>
> Thoughts?
I've been switching the directories to {dmd, dmd2} so they can coexist.

On Thu, Jul 23, 2009 at 1:20 PM, Steven
Schveighoffer<schveiguy@yahoo.com> wrote:
>
> However, when I realized that with a custom allocator, I could tremendously
> increase performance, I had to switch to structs.
Um, did you? Because you can have custom allocators for classes too..

On Thu, Jul 23, 2009 at 1:59 PM, Walter
Bright<newshound1@digitalmars.com> wrote:
> Michel Fortin wrote:
>>
>> If I'm not mistaken, both your D1 and D2 installer install at the same
>> location and they will overwrite each other. I'd much prefer if D2 and D1
>> could coexist without having to go with a special installer or custom
>> installation instructions. Otherwise it'll be hard for me to offer the
>> choice between D1 and D2 in Xcode (and I certainly do want that choice to be
>> available).
>>
>> Thoughts?
>
> I've been switching the directories to {dmd, dmd2} so they can coexist.
Will you rename the DMD2 compiler to 'dmd2' as well?

Knud Soerensen wrote:
> Some time ago I need a script to get and process some data.
> I trough why not use D, but I couldn't find a function in the standard
> library which would get a simple web page with http.
> Instead of find and downloading other libraries I switched to peal and
> had it running in no time.
>
> I think it is the choice of problem domain for D.
I'd love to have some functions in Phobos that do this. Can you write a
module and contribute it? Phobos is definitely short on a lot of
networking functionality.
> I know the real focus for D system programing and the C++ people.
>
> I think one of D's strongest points for people to make the switch is
> build in unit testing. (at least this is the strongest point for me)
> But the very simple implementation of unit testing in D nearly ruin the
> advantage it gives. (see suggestion from the wishlist below)
Even at its very simple support, it's a huge win. It raises the bar on
what is minimally acceptable, and has been responsible for a big
improvement in the quality of Phobos.
> A simple way to ensure that could if the compiler issued a error/warning
> if a function had no unit tests or contracts.
I worry that such would be crying wolf. But dmd does have a coverage
analyzer built in - which I think is more useful. It'll show which lines
were executed by the unit tests, and which were not.
>
> What follows is some unit test suggestions from
> http://all-technology.com/eigenpolls/dwishlist
> Because I would like to hear your opinion about them.
>
> ** unit test & code separation
> I think it would be more useful if the code
> and the unit test where two separate binaries.
>
> Sometimes you need to move the production binary to another
> machine/environment.
> It would be nice if one could move the test binary with it and test that
> everything works.
>
> It would also allow for arguments to the test binary,
> so that you would be able to run a specific unit test.
I made the decision at one point that unit tests weren't there to test
that the compiler generated code correctly, they were to test the logic
of the user code. Hence, one does a separate build for unit tests than
production release.
The release version should get the black box tests, not unit tests.
> ** black box unit testing
> The d compiler should enforce black box unit tests.
>
> Which is unit tests that only use the classes exposed interface.(public,
> protected)
>
> Together with 100% unit test coverage it helps ensure that
> the code is modular,decoupled and that you can change
> the private parts without changing the unit tests.
>
> For those how is not ready for this high code standard,
> there might be a --allow-white-box switch.
The compiler doesn't need to help here. There's nothing preventing one
from using unittests in this manner. Just import the .di file, which is
the exposed interface, then write a unit test block.
> ** Unit test isolation
> I would like to be able to isolate the unit test,
> so that if one fail the next still runs.
You can do this by simply not using "assert" for the actual test. Use:
if (!x) writeln("test for x failed");
instead of:
assert(x);
You can, of course, make a template like Andrei's enforce() to make the
if test and message a bit more convenient.
> ** Unit test measurements
> In combination with test isolation
> it would be nice to have d output
> memory and time used in each unit test.
Use the -profile switch.

Jarrett Billingsley wrote:
> On Thu, Jul 23, 2009 at 1:59 PM, Walter
> Bright<newshound1@digitalmars.com> wrote:
>> Michel Fortin wrote:
>>>
>>> If I'm not mistaken, both your D1 and D2 installer install at the same
>>> location and they will overwrite each other. I'd much prefer if D2 and
>>> D1 could coexist without having to go with a special installer or custom
>>> installation instructions. Otherwise it'll be hard for me to offer the
>>> choice between D1 and D2 in Xcode (and I certainly do want that choice
>>> to be available).
>>>
>>> Thoughts?
>>
>> I've been switching the directories to {dmd, dmd2} so they can coexist.
>
> Will you rename the DMD2 compiler to 'dmd2' as well?
That would be very convenient, please consider this.

Lutger wrote:
> Jarrett Billingsley wrote:
>
>> On Thu, Jul 23, 2009 at 1:59 PM, Walter
>> Bright<newshound1@digitalmars.com> wrote:
>>> Michel Fortin wrote:
>>>> If I'm not mistaken, both your D1 and D2 installer install at the same
>>>> location and they will overwrite each other. I'd much prefer if D2 and
>>>> D1 could coexist without having to go with a special installer or custom
>>>> installation instructions. Otherwise it'll be hard for me to offer the
>>>> choice between D1 and D2 in Xcode (and I certainly do want that choice
>>>> to be available).
>>>>
>>>> Thoughts?
>>> I've been switching the directories to {dmd, dmd2} so they can coexist.
>> Will you rename the DMD2 compiler to 'dmd2' as well?
>
> That would be very convenient, please consider this.
>
I think moving forward D2 will be the norm, so I suggest going with dmd1
and dmd dir names and dmd1 and dmd binary names.
Andrei