C, comments on your comments below.  Thanks for your answers.

> > - Boolean: I think for a C person (and I was one, long time
>
> bit , bool ?

Is there a bool type in D?  It's not mentioned in the spec.

> > - Abstract Classes: why do you have to implement the
> Isnt that why people like them ( I just got ATL 3.0 workshop , and reading up on interfaces as I have never used them before ) , they force you to override the functions ?

Well, a concrete class should indeed implement them, an abstract class not necessarily.

> > - Is there the need for a Collections library?
> I've created a Deque class that does autmoatic array resizing , but
besides
> that little catch the built in dynamic arrays cover just about everything else.

I agree that a resizable array is 50% of what you need 80% of
the time, but ... how about generic hash tables (like associative
arrays for any type, not just strings), or sets, or graphs, or ...

> > - Interned Strings:
> WYSIWYG strings ?  if so we have those with ` ` ( backticks )

Sorry for not making myself clear.  Interned strings are strings that
live in the constant pool, so the same string only has one representation,
and indentity tests (instead of equality tests) always hold.
I realize it's not very intuitive to understand the need until you use
them or you program in lisp.

> > - Properties: I don't like that D forces me to use an ugly name
> you can use any name u want , but Ive run into a couple problems with properties , im not exactly sure how they work ( or are supposed to work )

Well, I can't name them however I want, because the compiler says there is an ambiguity if I name them the same as the function.

> > - Instanceof: doing "a instanceof B" is some much nicer
> You mean 'is' ?
> if ( x is null  ) fail();

Is there a "is" operator in D?

> > - Concatenation:
> D has it , the ~ is concatentation.

But it does not auomatically concatenate strings and integers, that was my point.

Cheers,

Andres

> Is there a bool type in D?  It's not mentioned in the spec.
There is a bit , which is aliased to bool somewhere in phobos.

> Well, a concrete class should indeed implement them, an abstract class not necessarily.
Ahh i see what u mean.

> I agree that a resizable array is 50% of what you need 80% of
> the time, but ... how about generic hash tables (like associative
> arrays for any type, not just strings), or sets, or graphs, or ...

associatave , dynamic ( all ) arrays work for any type.

> Well, I can't name them however I want, because the compiler says there is an ambiguity if I name them the same as the function.
you cant name members the same as methods no , but this isnt a restritcion on properties , but overall.

> Is there a "is" operator in D?
yes.

> But it does not auomatically concatenate strings and integers, that was my point.

Autmoatically ? no

char [] foo = "My string is " ~ toString(21) ~ " charaters long";

C

"Andres Rodriguez" <rodriguez@ai.sri.com> wrote in message news:bvrr0l$2oi4$1@digitaldaemon.com...
>
> C, comments on your comments below.  Thanks for your answers.
>
> > > - Boolean: I think for a C person (and I was one, long time
> >
> > bit , bool ?
>
> Is there a bool type in D?  It's not mentioned in the spec.
>
> > > - Abstract Classes: why do you have to implement the
> > Isnt that why people like them ( I just got ATL 3.0 workshop , and
reading
> > up on interfaces as I have never used them before ) , they force you to override the functions ?
>
> Well, a concrete class should indeed implement them, an abstract class not necessarily.
>
> > > - Is there the need for a Collections library?
> > I've created a Deque class that does autmoatic array resizing , but
> besides
> > that little catch the built in dynamic arrays cover just about
everything
> > else.
>
> I agree that a resizable array is 50% of what you need 80% of
> the time, but ... how about generic hash tables (like associative
> arrays for any type, not just strings), or sets, or graphs, or ...
>
> > > - Interned Strings:
> > WYSIWYG strings ?  if so we have those with ` ` ( backticks )
>
> Sorry for not making myself clear.  Interned strings are strings that
> live in the constant pool, so the same string only has one representation,
> and indentity tests (instead of equality tests) always hold.
> I realize it's not very intuitive to understand the need until you use
> them or you program in lisp.
>
> > > - Properties: I don't like that D forces me to use an ugly name
> > you can use any name u want , but Ive run into a couple problems with properties , im not exactly sure how they work ( or are supposed to
work )
>
> Well, I can't name them however I want, because the compiler says there is an ambiguity if I name them the same as the function.
>
> > > - Instanceof: doing "a instanceof B" is some much nicer
> > You mean 'is' ?
> > if ( x is null  ) fail();
>
> Is there a "is" operator in D?
>
> > > - Concatenation:
> > D has it , the ~ is concatentation.
>
> But it does not auomatically concatenate strings and integers, that was my point.
>
> Cheers,
>
> Andres
>
>

> > > - Concatenation:
> > D has it , the ~ is concatentation.
>
> But it does not auomatically concatenate strings and integers, that was my point.

Since ~ acts on any array, not just strings, would you expect it to try to automatically convert an integer to a "compatible" array and concatenate that? Would there be some special cases for strings? Personally I like keeping ~ simple and making the user turn non-array into arrays by hand. It isn't that much more to type and removes special cases.

-Ben

Carlos Santander B. wrote:

> Comments embedded, quote trimmed.
> 
> Andres Rodriguez wrote:
> 
>>2) Education
>>
>>I think the manual as it is if fine, but it's almost a description
>>of the grammar mixed with illustrating comments.  There is
> 
> 
> I never saw it as a manual, because the name is "D Language Specification".
> 
> 
>>the need for more comprehensive examples on the use of
>>the language.  Also a longer more complete FAQ, including
>>all the possibly important questions that are posed
>>again and again in the newsgroup: "why isn't there a
>>boolean type" (my own below). "why is there no inner
> 
> 
> Check out the wiki: http://www.prowiki.org/wiki4d/ (that's it, right?)
Try...
http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit

The links at the bottom are to THREADS. There have probably been 100 or 150 messages regarding the (alleged) deficiencies of D's bit. Walter's still unconvinced. I think the status quo is going to win this one.

-- 
Justin
http://jcc_7.tripod.com/d/

In article <bvri3h$29sa$1@digitaldaemon.com>, Achilleas Margaritis says...
>
>A better alternative of 'instanceof' is the word 'is'. Example
>
>If (a is B) {
>}
>

Why not isa? If foo is a Bar, then why not have the operator called that?

if (a isa B) {}

>> - Templates: the templates part of the language seems to be
>> the weakest, with few examples and an akward syntax.  And I
>> am not talking about the Foo<int> vs Foo(int) issue.  I really don't
>> care about that, and if it keeps the grammar simpler, much better.
>> I am talking about writing a generic function for "max", which
>> is the "hello world" of templates.  It requires way too much code,
>> and before seeing some example in the newsgroup, I was
>> even wondering if it was possible.
>
>What about:
>    template max(T) {
>        T max ( T a, T b ) {
>            if (a>b) return a;
>            return b;
>        }
>    }
>?

To cite it again: "It requires way too much code". Your example doesn't change it.

>shorts (16-bit int)
>
>They have their use for instance in digital audio where your samples are 16-bit. If you want to fill a wave buffer, you need shorts.
>
>floats (32-bit float)
>
>They are needed for instance if you want to fill a buffer with 3D-data and upload them to your graphics card.
>
Well I need 32-bit floats for digital audio processing. :)

>- Boolean: I think for a C person (and I was one, long time
>ago) it might look natural to do a condition using integers,
>but I believe it helps so much to the readibility of the
>language to have a boolean type.  Just in the LinkedList
>example I was reading I was confused by something
>like:
>
>if (list.length) { ... }
>
>Isn't much nicer to read:
>
>if (list.length == 0) { ... }
>
>I realize this has probably been touched on many times, but I thought I would give my 2 cents.

There is a boolean type called bool. Anyway, you can still write if (list.length) { ... }


>- Abstract Classes: why do you have to implement the
>whole interface that you are trying to extend?  I sent a
>message regarding this yesterday.  I do not know if it is
>a bug or a feature.
I never got that, too.


>- Is there the need for a Collections library?  I think one of
>the things Java got right is its collection library.  Most of the
>comments about the complexity of C++ also apply to STL.
>Java has a nice, small and usable Collections library.  Someone
>knows if it is legal to copy Sun's design for this?
Hm, I prefer STL over Javas collections.


>- Types: why keep the "uint", "ulong", ... types around.  I
>am of the idea that the fewer basic types you have, the better.
>It would actually be nice if we got rid of "float", but maybe
>that's because I am not a numerical programmer (and some
>of them would want to kill me for suggesting this).  I see how
>having a "uint" makes your code simpler (i.e. no need to check
>wether an index is >= than zero), but I like the simplicity
>of very few types.  What do we need short for?  If you need
>to save space, then use bytes, otherwise just use int.  Am I
>being too simplistic?  I am very ignorant in this aspect, so
>please feel free to tell me that I am way wrong here.
You're kidding, aren't you?


>- Interned Strings: a nice feature in Java are interned
>strings.  Coming from Lisp, it's a nice compromise
>between symbols and strings.  They are useful in parsing
>XML, in implementing Knowledge Bases, and in general
>in doing symbolic programming.  I have no idea if this
>is hard or easy to implement (or if D already has it
>and I don't know).
Yes, that would be nice (, but I'm not sure if D already has it, too).


>- Properties: I don't like that D forces me to use an
>ugly name (for me of course, uglyness is a personal quality)  like
>"m_data" when I define a property.  In the example in the
>manual:
>
>struct Foo
>	{
>	    int data() { return m_data; }	// read property
>
>	    int data(int value) { return m_data = value; } // write property
>
>	  private:
>	    int m_data;
>	}
>
>I rename "m_data" to "data" (the compiler wont let me) even though the "m_data" field is private.  There might some ambiguity inside the class, but there could be rules to avoid this (like inside the class always use the private one).
This is something we should think about.


>- Friends: from a software engineering point of view, I find declaring a class "friends" with some other class very useful. Sometimes you are declaring a Class, and in your head you say, "ok, this class can only be maniuplated from this type of classes", and in order to achieve that you have to make it accessible to a whole package (In D or Java).  This is a nice feature of C++, although I can see why it is debatable.

AFAIK all classes within a modul can access privat members of other class in the same modul. But I've never tested that.


>- Readonly: readonly properties would go a long way
>into implementing most of what you want from a property,
>without going through the detour of defining "getter" and
>"setter" functions.  They are more efficient or don't require
>compiler inlining.  It seems like such an easy way out of
>the "getter and getter" nightmare that I wonder if I am
>missing something here (as to why nobody has done it,
>not even lisp which is usually really good about this type
>of stuff).
You got my vote.


>- Instanceof: doing "a instanceof B" is some much nicer
>and readable than "((B) a)".  Why not have it in the language
>as a synonym?
"((B) a)" is the old cast-synthax. You should use the new one: "(cast(B) a)".

But why?

if (a instanceof B)
{
B b = cast(B)a;
..
}

B b = cast(B)a;
if (b !== null)
{
..
}

The first versionwould have to check the type twice. When do you need it?


>- Global identifier: the identifier for global is ugly.  Writing ".toString(2)" does not seem very nice, but I do not have any suggestions as to how to make it better/nicer.  What I find ugly about it, just to make myself clear is the fact that the dot "." is being applied to anything.  I know C++ uses "::", but even that seems a little more balance than a single dot.
That's exactly my opinion, but many others like it the way it is :(


>- Concatenation: as someone suggested on the newgroup
>recently, in Java it is very nice to be able to write "value: " ~ 2.
>Is it possible to implement it in D?  Is one of those things that
>don't seem very orthogonal with the rest of the language, but
>that are very practical and useful.

what about

Foo[] myArray;
myArray ~ 2;  // what happens here?

Andres Rodriguez wrote:
> [...]
> 
> 5) Language Issues (small and big)
> 
> - Boolean: I think for a C person (and I was one, long time
> ago) it might look natural to do a condition using integers,
> but I believe it helps so much to the readibility of the
> language to have a boolean type.  Just in the LinkedList
> example I was reading I was confused by something
> like:
> 
> if (list.length) { ... }
> 
> Isn't much nicer to read:
> 
> if (list.length == 0) { ... }
> 
> I realize this has probably been touched on many times, but
> I thought I would give my 2 cents.

I'd prefer that integers couldn't be implicitly converted to booleans, but you can't win them all, I guess.

> 
> - Is there the need for a Collections library?  I think one of
> the things Java got right is its collection library.  Most of the
> comments about the complexity of C++ also apply to STL.
> Java has a nice, small and usable Collections library.  Someone
> knows if it is legal to copy Sun's design for this?

I'm pretty sure you can't own an interface.  As long as you're not copying from source, I don't see why not.

> 
> - Unit Testing: is porting JUnit to D a good idea?  apart
> from the "unitest" block in D, I don't see much support for
> building test cases and running them separately.  This is
> also an area the manual is lacking in, it mentions unit
> testing, but there is no documentation on it.

More D is a good thing.

> 
> - Arrays being Objects: I also initiated a discussion on
> this on the newsgroup.  After seeing the answer I have
> a practical final comment, aside from how hard or
> easy it is implement.  Having something like this will
> a) not break any exisiting code, and b) make life easier
> for people porting stuff from Java.  So I cannot see
> how this can be a bad thing, except for being hard
> to implement, ot bringing efficiency down.

One of the main goals of D is that it be easy to compile.  It's nice to be able to expect D compilers to work correctly. (unlike, say, C++) This also tends to have the side effect of making compilation quite fast.

> 
> - Interned Strings: a nice feature in Java are interned
> strings.  Coming from Lisp, it's a nice compromise
> between symbols and strings.  They are useful in parsing
> XML, in implementing Knowledge Bases, and in general
> in doing symbolic programming.  I have no idea if this
> is hard or easy to implement (or if D already has it
> and I don't know).

I assume the compiler could handle this.  Arrays (not just strings) can be compared with the == operator.  I would think that checking identity before comparing elements would achieve this.

> 
> - Properties: I don't like that D forces me to use an
> ugly name (for me of course, uglyness is a personal quality)  like
> "m_data" when I define a property.  In the example in the
> manual:
> 
> struct Foo
> 	{
> 	    int data() { return m_data; }	// read property
> 
> 	    int data(int value) { return m_data = value; } // write property
> 
> 	  private:
> 	    int m_data;
> 	}
> 
> I rename "m_data" to "data" (the compiler wont let me) even
> though the "m_data" field is private.  There might some ambiguity
> inside the class, but there could be rules to avoid this (like
> inside the class always use the private one).

Allowing that would mean that the compiler would have to guess what you mean.  If it guesses wrong, you are in big trouble. :)

> 
> - Friends: from a software engineering point of view, I find
> declaring a class "friends" with some other class very useful.
> Sometimes you are declaring a Class, and in your head you
> say, "ok, this class can only be maniuplated from this type
> of classes", and in order to achieve that you have to make it
> accessible to a whole package (In D or Java).  This is a nice
> feature of C++, although I can see why it is debatable.

Friends only extend to the module scope in D, not package.

> 
> - Readonly: readonly properties would go a long way
> into implementing most of what you want from a property,
> without going through the detour of defining "getter" and
> "setter" functions.  They are more efficient or don't require
> compiler inlining.  It seems like such an easy way out of
> the "getter and getter" nightmare that I wonder if I am
> missing something here (as to why nobody has done it,
> not even lisp which is usually really good about this type
> of stuff).

In Ruby, attributes can be set to be read-only, unless a method has access to private scope.  This would be nice.

> 
> - Side effects: Accessing a property should not have side
> effects, this seems conterintuitive.  Specifically I am talking
> about things like "sort" in arrays.  I am willing to think that I
> have been entrained by other languages, so please convince
> me it is the right thing to do.

Semantically, I agree, but the demands of the hardware cannot be ignored.  Sorting in-place is much more efficient, and is often what people want to accomplish anyway.  myarray = myarray.sort would not be terribly efficient. :)

If you want a sorted copy, you can say myarray.dup.sort

> 
> - Global identifier: the identifier for global is ugly.  Writing
> ".toString(2)" does not seem very nice, but I do not have any
> suggestions as to how to make it better/nicer.  What I find
> ugly about it, just to make myself clear is the fact that the
> dot "." is being applied to anything.  I know C++ uses "::",
> but even that seems a little more balance than a single dot.

It's simple, and relatively consistent with how the dot operator works.  In general, it doesn't see much use, except with the toString functions sitting in std.string.

> 
> - Concatenation: as someone suggested on the newgroup
> recently, in Java it is very nice to be able to write "value: " ~ 2.
> Is it possible to implement it in D?  Is one of those things that
> don't seem very orthogonal with the rest of the language, but
> that are very practical and useful.

I wrote a formatter object thing that accomplishes nearly this.

> 
> - Templates: the templates part of the language seems to be
> the weakest, with few examples and an akward syntax.  And I
> am not talking about the Foo<int> vs Foo(int) issue.  I really don't
> care about that, and if it keeps the grammar simpler, much better.
> I am talking about writing a generic function for "max", which
> is the "hello world" of templates.  It requires way too much code,
> and before seeing some example in the newsgroup, I was
> even wondering if it was possible.

I find them to be quite sufficient, and easier to work with than C++ templates, but I tend to use them to parameterize classes, not write higher-order functions and the like. (for which they're not so hot, as there is no type deduction)

> 
> 6) Conclusion
> 
> I am very excited about being able to work with language like
> D, and I would like it to gain momentum.  I am here to help,
> so please let me know how can I do that.  I have started writing
> a Java -> D translator to port some of my code and play a little
> more with D.  But as I said, I am very impressed with everything
> I have seen.

As said, more D code is a good thing. :)

 -- andy

>> - Templates: the templates part of the language seems to be
>> the weakest, with few examples and an akward syntax.  And I
>> am not talking about the Foo<int> vs Foo(int) issue.  I really don't
>> care about that, and if it keeps the grammar simpler, much better.
>> I am talking about writing a generic function for "max", which
>> is the "hello world" of templates.  It requires way too much code,
>> and before seeing some example in the newsgroup, I was
>> even wondering if it was possible.
>
>I find them to be quite sufficient, and easier to work with than C++ templates, but I tend to use them to parameterize classes, not write higher-order functions and the like. (for which they're not so hot, as there is no type deduction)

You have typeof, so you can do typededuction. But it's still ugly.