All people here allwas say: "D is great!". So it seems like I'm stupid or something. Every second program I try to write using D doesn't work because of some unexpected behavor of D.

E.g.

This works:

class Foo {
Foo recursive;
}

This works:

class Bar (T) {
T value;
}

So is it realy that stupid that this works:

class Baz (T) {
Baz!(T) recursive;
}


Everytime I try to code anything in D I get such behavior that I don't expect and often I don't find a workaround. But "D is so great". So are my ideas so strange that nobody else wants to do the things I want to? Why does nobody else say D is strange with a lot of unexpected behaviors?


BTW: Why structs don't have constructors? I get crazy about this!

Foo foo;
foo.x = bla;
foo.y = blub;
// start using foo
// *ARGH!!!*

It's so messy.



Even experienced programmers like Andy F. are fooled by the language. We wanted to simulate the simple ML-line

fun mul x y = x * y

So he wrote:

template MulReturnType (T, U) {
alias typeof(T.init * U.init) MulReturnType;
}


template mul (T, U) {
MulReturnType!(T, U) mul (T x, U y)
{
return x * y;
}
}


Of course this doesn't work, as you can overload opMul and structs and classes don't have an init-property. So you have to use an even more clumsy workaround:

template MulReturnType (T, U) {
T tValue;
U uValue;
alias typeof(tValue * uValue) ReturnType;
}

template mul (T, U) {
MulReturnType!(T, U).ReturnType mul (T x, U y)
{
return x * y;
}
}


And this is needed only for one very simple line of ML!

OK, perhaps Andy just expected other programmers to be smart enough to write a init-property for types that should be useable in istuations like this?



BTW, can somebody tell me for what reason you want to overload opMul for a
class? I expect to use op * only on things like numbers. But numbers are
valu-etypes not reference-types. A number is defined by its value. You can sotre
it a million times at different places, it's allways the same number if it has
the same value. This is totaly different to reference-types. E.g. a Car is
identifyed by its identity, not its value. if you have two cars, both are red
and both are build 1995 it doesn't mean that they are the same cars. Their
values isn't interesting, but their identity.
D is powerfull enough to express something like this: You can use class for
identity-defined-objects and struct for value-defined-objects. (OK, than you
once again have the problem that structs doen't have a c'tor!)

Could anybody explain me, in which I you'd want to overload opMul on classes?


The more I use D the less I like it. But it's defently me, as "D is so great!".

I think you need to do .Baz!(T) recursive;
I complained about this when I was first on the board as well :-)
the . tells the compiler to resolve the symbol from the global scope

Matthias Becker wrote:
> All people here allwas say: "D is great!". So it seems like I'm stupid or
> something. Every second program I try to write using D doesn't work because of
> some unexpected behavor of D.
> 
> E.g.
> 
> This works:
> 
> class Foo {
> Foo recursive;
> }
> 
> This works:
> 
> class Bar (T) {
> T value;
> }
> 
> So is it realy that stupid that this works:
> 
> class Baz (T) {
> Baz!(T) recursive;
> }
> 
> 
> Everytime I try to code anything in D I get such behavior that I don't expect
> and often I don't find a workaround. But "D is so great". So are my ideas so
> strange that nobody else wants to do the things I want to? Why does nobody else
> say D is strange with a lot of unexpected behaviors?
> 
> 
> BTW: Why structs don't have constructors? I get crazy about this!
> 
> Foo foo;
> foo.x = bla;
> foo.y = blub;
> // start using foo
> // *ARGH!!!*
> 
> It's so messy.
> 
> 
> 
> Even experienced programmers like Andy F. are fooled by the language. We wanted
> to simulate the simple ML-line
> 
> fun mul x y = x * y
> 
> So he wrote:
> 
> template MulReturnType (T, U) {
> alias typeof(T.init * U.init) MulReturnType;
> }
> 
> 
> template mul (T, U) {
> MulReturnType!(T, U) mul (T x, U y)
> {
> return x * y;
> }
> }
> 
> 
> Of course this doesn't work, as you can overload opMul and structs and classes
> don't have an init-property. So you have to use an even more clumsy workaround:
> 
> template MulReturnType (T, U) {
> T tValue;
> U uValue;
> alias typeof(tValue * uValue) ReturnType;
> }
> 
> template mul (T, U) {
> MulReturnType!(T, U).ReturnType mul (T x, U y)
> {
> return x * y;
> }
> }
> 
> 
> And this is needed only for one very simple line of ML!
> 
> OK, perhaps Andy just expected other programmers to be smart enough to write a
> init-property for types that should be useable in istuations like this?
> 
> 
> 
> BTW, can somebody tell me for what reason you want to overload opMul for a
> class? I expect to use op * only on things like numbers. But numbers are
> valu-etypes not reference-types. A number is defined by its value. You can sotre
> it a million times at different places, it's allways the same number if it has
> the same value. This is totaly different to reference-types. E.g. a Car is
> identifyed by its identity, not its value. if you have two cars, both are red
> and both are build 1995 it doesn't mean that they are the same cars. Their
> values isn't interesting, but their identity.
> D is powerfull enough to express something like this: You can use class for
> identity-defined-objects and struct for value-defined-objects. (OK, than you
> once again have the problem that structs doen't have a c'tor!)
> 
> Could anybody explain me, in which I you'd want to overload opMul on classes?
> 
> 
> The more I use D the less I like it. But it's defently me, as "D is so great!".
> 
> 

Matthias Becker wrote:

> Could anybody explain me, in which I you'd want to overload opMul on classes?

Well, one VERY well known example is for vector or matrix classes that can be multiplied, but in a more complex way than just x * y.

Lars Ivar Igesund

IMO, there are a number of areas where D blows chunks rather offensively. And then there's a number places where flaccid hacks (such as alias) are documented as the "right approach". To my mind, there's so much time spent trying to include every latest fad into the language that there's not enough left over to get some of the basics right.

That's not to say that D sucks overall; it doesn't. It's more an issue of time versus functionality versus getting it right. I've personally avoided templates specifically because I don't want immature compiler dependencies in my code, but still I'm frustrated and seriously hindered by a lack of basic functionality such as function-overloading that actually includes the method signature in all situations. Imagine that!.

To alleviate some of the pressure, it would likely help if the language development were much more open in terms of disclosure: what is being addressed sooner rather than later has a significant perceptive impact. However, such things take a reasonable amount of effort and I don't see Walter selecting any lieutenants to help him out ...

- Kris


"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:ccth2r$tg7$1@digitaldaemon.com...
> All people here allwas say: "D is great!". So it seems like I'm stupid or something. Every second program I try to write using D doesn't work
because of
> some unexpected behavor of D.
>
> E.g.
>
> This works:
>
> class Foo {
> Foo recursive;
> }
>
> This works:
>
> class Bar (T) {
> T value;
> }
>
> So is it realy that stupid that this works:
>
> class Baz (T) {
> Baz!(T) recursive;
> }
>
>
> Everytime I try to code anything in D I get such behavior that I don't
expect
> and often I don't find a workaround. But "D is so great". So are my ideas
so
> strange that nobody else wants to do the things I want to? Why does nobody
else
> say D is strange with a lot of unexpected behaviors?
>
>
> BTW: Why structs don't have constructors? I get crazy about this!
>
> Foo foo;
> foo.x = bla;
> foo.y = blub;
> // start using foo
> // *ARGH!!!*
>
> It's so messy.
>
>
>
> Even experienced programmers like Andy F. are fooled by the language. We
wanted
> to simulate the simple ML-line
>
> fun mul x y = x * y
>
> So he wrote:
>
> template MulReturnType (T, U) {
> alias typeof(T.init * U.init) MulReturnType;
> }
>
>
> template mul (T, U) {
> MulReturnType!(T, U) mul (T x, U y)
> {
> return x * y;
> }
> }
>
>
> Of course this doesn't work, as you can overload opMul and structs and
classes
> don't have an init-property. So you have to use an even more clumsy
workaround:
>
> template MulReturnType (T, U) {
> T tValue;
> U uValue;
> alias typeof(tValue * uValue) ReturnType;
> }
>
> template mul (T, U) {
> MulReturnType!(T, U).ReturnType mul (T x, U y)
> {
> return x * y;
> }
> }
>
>
> And this is needed only for one very simple line of ML!
>
> OK, perhaps Andy just expected other programmers to be smart enough to
write a
> init-property for types that should be useable in istuations like this?
>
>
>
> BTW, can somebody tell me for what reason you want to overload opMul for a class? I expect to use op * only on things like numbers. But numbers are valu-etypes not reference-types. A number is defined by its value. You can
sotre
> it a million times at different places, it's allways the same number if it
has
> the same value. This is totaly different to reference-types. E.g. a Car is identifyed by its identity, not its value. if you have two cars, both are
red
> and both are build 1995 it doesn't mean that they are the same cars. Their
> values isn't interesting, but their identity.
> D is powerfull enough to express something like this: You can use class
for
> identity-defined-objects and struct for value-defined-objects. (OK, than
you
> once again have the problem that structs doen't have a c'tor!)
>
> Could anybody explain me, in which I you'd want to overload opMul on
classes?
>
>
> The more I use D the less I like it. But it's defently me, as "D is so
great!".
>
>

Matthias Becker wrote:

> 
> BTW: Why structs don't have constructors? I get crazy about this!
> 
> Foo foo;
> foo.x = bla;
> foo.y = blub;
> // start using foo
> // *ARGH!!!*
> 
> It's so messy.

struct Foo
{
   int x;
   static Foo opCall(int i)
   {
       Foo f;
       f.x = i;
       return f;
   }
}

Foo foo = Foo(5);

While D has many similarities to other languages, D is D. There are quite a few small things that will bite you if you are thinking in C++ (or Java or whatever). Things won't always work as you expect them to, or you'll find there's a different way of doing something. It's when you've learnt the nuances and begun to 'think in D' that you realize how great D is ;)

Spend some time reviewing the tutorials at dsource.org and perhaps the Wiki. In addition to covering common pitfalls and mistakes, they also have tidbits which fill in gaps in the documentation.

In article <ccthi2$ucn$1@digitaldaemon.com>, Lars Ivar Igesund says...
>
>Matthias Becker wrote:
>
>> Could anybody explain me, in which I you'd want to overload opMul on classes?
>
>Well, one VERY well known example is for vector or matrix classes that can be multiplied, but in a more complex way than just x * y.
>
>Lars Ivar Igesund

Also the Int class (unlimited precision integer) in etc.bigint.bigint.

Arcane Jill

>struct Foo
>{
>    int x;
>    static Foo opCall(int i)
>    {
>        Foo f;
>        f.x = i;
>        return f;
>    }
>}
>
>Foo foo = Foo(5);

D'oh. It's so obvious. I should have thougt about that.

In article <cctj4p$115q$1@digitaldaemon.com>, Mike Parker says...

>struct Foo
>{
>    int x;
>    static Foo opCall(int i)
>    {
>        Foo f;
>        f.x = i;
>        return f;
>    }
>}
>
>Foo foo = Foo(5);

See, Walter. I told you - people are using static opCall to simulate constructors. You can do this for both structs and classes. For structs, the advantage is, you GET constructor-like calls. For classes, the advantage is, you get to dispense with the unnecessary word "new".

I have suggested this before (though I gather you didn't like the suggestion)
that (1) structs should be allowed constructors; (2) the keyword "new" should be
ditched, or at least made optional, in constructor calls; and (3) static opCall
be deprecated in favor of constructors. The language would be SO much neater and
cleaner with these changes built in.

I find it hard to believe, after all, that the use of static opCall as demonstrated above was a DESIGN FEATURE of D. I mean - I've never seen static opCall used for any purpose OTHER than emulating constructors. I find it more believable that someone simply discovered that the compiler lets you get away with it, and started using it because structs don't have constructors. It would be really nice to tidy this up - even if only for syntactic consistency.

Arcane Jill

> class Baz (T) {
> Baz!(T) recursive;
> }

class Baz(T)
{
    Baz recursive;
}

Matthias Becker wrote:

> Even experienced programmers like Andy F. are fooled by the language. We wanted to simulate the simple ML-line
> 
> fun mul x y = x * y

The philosophy of ML and D is completely different. If you think ML while trying  to program D, the result will definitely be messy. The same happens the other way around.

The great strength of ML is the type deduction, allowing you to write generic functions at great ease.

The great drawback of ML, though, is type deduction, forbidding you to do function overloading.

Actually, I used O'Caml for some time and I really began to love it. Anyhow, after a while, I realized that the lack of function overloading really was weighing too heavily for me. Especially in numerics, function overloading really is an important aspect.

D has some room for improvement left, but trying to compare it to ML will never be fair on either of the two languages.