Matthias Becker wrote:

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

Yes, it certainly is you - or better - your background in ML. Switching over to D, you will have to change your way of thinking fundamentally.

A Chinese visiting Africa will go through hard times finding that life is different there. In the end, he might either give up, go home and tell people about those crazy Africans that do everything the wrong way. Or he might stay long enough to learn loving the country, learn new things, go home and bring new ideas with him. Or he stays even longer and starts feeling at home and decides to stay there.

I just hope that you won't belong to the first group but stay open for intercultural exchange.

>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.
>

There actualy are languages that can do both. Functional and oo-languages. E.g. in C++ you can have both:

void foo (int x)   // used for ints
{...}

template <typename T>   // used for everything else
void foo (T x)
{...}

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

Of course. Something like the powerfull pattern matching mechanism isn't possible in D without making big changes in the language. There is something called JMatch (a Java extension) that allows this. Constructors (and any other function for doing some logical programming) can have a foreward and a backward-modes.


I suggested some time ago a possible way.

something like:
var foo = <expression>;

if you use the keyword var the type is deduced/infered from the expression that is assigend.

so
var foo = 22;
means
int foo = 22;
and
var bar = 1.5;
means
double bar = 1.5;

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:ccu0nl$1lgk$1@digitaldaemon.com...
> >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.
> >
>
> There actualy are languages that can do both. Functional and oo-languages.
E.g.
> in C++ you can have both:
>
> void foo (int x)   // used for ints
> {...}
>
> template <typename T>   // used for everything else
> void foo (T x)
> {...}
>
> >D has some room for improvement left, but trying to compare it to ML will never be fair on either of the two languages.
>
> Of course. Something like the powerfull pattern matching mechanism isn't possible in D without making big changes in the language. There is
something
> called JMatch (a Java extension) that allows this. Constructors (and any
other
> function for doing some logical programming) can have a foreward and a backward-modes.
>
>
> I suggested some time ago a possible way.
>
> something like:
> var foo = <expression>;
>
> if you use the keyword var the type is deduced/infered from the expression
that
> is assigend.
>
> so
> var foo = 22;
> means
> int foo = 22;
> and
> var bar = 1.5;
> means
> double bar = 1.5;

I believe this feature is very important, and will be needed. It's likely to be featured in the next version of C++.

> 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.
> 

A cleaner syntax for initializing structs (like the one that already exists for static structs) has been requested in the past. Something simple like

 Foo foo = {bla, blub};

being syntactic sugar for

 Foo foo;
 foo.x = bla;
 foo.y = blub;

I'm waiting for post-1.0 to see something like this as well as support for array and struct literals. Full-blown constructors are another story and much harder to justify adding to the language.

-Ben

Ben Hinkle 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.
>>
> 
> 
> A cleaner syntax for initializing structs (like the one that already exists
> for static structs) has been requested in the past. Something simple like
> 
>  Foo foo = {bla, blub};
> 
> being syntactic sugar for
> 
>  Foo foo;
>  foo.x = bla;
>  foo.y = blub;
> 
> I'm waiting for post-1.0 to see something like this as well as support for
> array and struct literals. Full-blown constructors are another story and
> much harder to justify adding to the language.
> 
> -Ben

What is wrong with:

Foo foo;
with(foo) { x = bla; y = blub; }

Clean as a whistle imo.

Ben Hinkle 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.
>>
> 
> 
> A cleaner syntax for initializing structs (like the one that already exists
> for static structs) has been requested in the past. Something simple like
> 
>  Foo foo = {bla, blub};
> 
> being syntactic sugar for
> 
>  Foo foo;
>  foo.x = bla;
>  foo.y = blub;
> 
> I'm waiting for post-1.0 to see something like this as well as support for
> array and struct literals. Full-blown constructors are another story and
> much harder to justify adding to the language.
> 
> -Ben

Doesn't this work?

Foo foo = {x:blah, y:blub};

-Chris S.
-Invironz

Arcane Jill wrote:
> I mean - I've never seen static
> opCall used for any purpose OTHER than emulating constructors.

In my quietly-under-development Neo server project, the DBObject class defines an opIndex for accessing its .properties and an opCall for accessing its .verbs.  Observe...

class DBObject {
  public:
    this(int _dbref) {
      dbref = _dbref;
    }

    // . . .

    DBProperty opIndex(int idx) {
      if (idx >= properties.length)
        return null;
      return properties[properties.keys[idx]];
    }

    DBProperty opIndex(char[] name) {
      if (name in properties)
        return properties[name];
      return null;
    }

    DBVerb opCall(int idx) {
      if (idx >= verbs.length)
        return null;
      return verbs[idx];
    }

    DBVerb opCall(char[] name) {
      foreach (DBVerb v; verbs) {
        if (v.matchName(name))  // because verb names are patterns
          return v;
      }
      return null;
    }
}

So there you go... if the code wants to access the ".(name)" property of an object in the database, it just uses 'obj["name"]'.  If it wants to get an assumed verb, it uses something like 'db[0]("do_login_command")' and voila.  The opCall overload has its uses besides emulating constructors.  And frankly, since we have the {...} literal syntax for structs, I don't see much need for struct constructors.

-Chris S.
-Invironz

"C. Sauls" <ibisbasenji@yahoo.com> wrote in message news:ccu5oc$1snh$2@digitaldaemon.com...
> Ben Hinkle 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.
> >>
> >
> >
> > A cleaner syntax for initializing structs (like the one that already
exists
> > for static structs) has been requested in the past. Something simple
like
> >
> >  Foo foo = {bla, blub};
> >
> > being syntactic sugar for
> >
> >  Foo foo;
> >  foo.x = bla;
> >  foo.y = blub;
> >
> > I'm waiting for post-1.0 to see something like this as well as support
for
> > array and struct literals. Full-blown constructors are another story and much harder to justify adding to the language.
> >
> > -Ben
>
> Doesn't this work?
>
> Foo foo = {x:blah, y:blub};
>
> -Chris S.
> -Invironz

That only works for static data - try it in a function and you'll get "variable foo is not a static and cannot have static initializer."

Ben Hinkle wrote:
> "C. Sauls" <ibisbasenji@yahoo.com> wrote in message
> news:ccu5oc$1snh$2@digitaldaemon.com...
>>Doesn't this work?
>>
>>Foo foo = {x:blah, y:blub};
>>
> That only works for static data - try it in a function and you'll get
> "variable foo is not a static and cannot have static initializer."

Ah.. I didn't realize that.  In that case, ew.  Maybe it could get a treatment rather like what array literals are getting... something like:

{Foo: x:blah, y:blub};

Although then the first : is possibly ambiguous?  Maybe array literals should use {} as well, instead of [].  Or structs should use [] in literals.  Ack, decisions decisions.

-Chris S.
-Invironz

Arcane Jill wrote:
> 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


I mostly agree with AJ here. The absence of struct constructors is an artificial and totally unnecessary restriction. And the argument that people would expect to have destructors as well is flawed, as has been shown in the numerous discussions of this topic. Also, recent postings here show that people WANT struct constructors and will resolve to hacks if they are not available.

However, I don't think the static opCall should be removed just yet. I'm not sure either if it is truly useful, but nothing like this is available in similar languages (C++, C#, Java), so I think it might take a while until its usefulness shows.

Besides, the non-static opCall HAS been used for string formatting and stream I/O. And I guess the static version could find similar uses with singleton classes.

Hauke