www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C#'s greatest mistakes

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://oredev.org/2010/sessions/c-s-greatest-mistakes

Andrei
Nov 26 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

A summary for those who don't want to sit through it: http://news.ycombinator.com/item?id=1942859
Nov 26 2010
next sibling parent reply Kagamin <spam here.lot> writes:
Walter Bright Wrote:

 Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

A summary for those who don't want to sit through it: http://news.ycombinator.com/item?id=1942859

Yeah, covariance. Can bug 2095 be fixed in D2? Or is it too late?
Nov 26 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/27/10 1:13 CST, Kagamin wrote:
 Walter Bright Wrote:

 Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

A summary for those who don't want to sit through it: http://news.ycombinator.com/item?id=1942859

Yeah, covariance. Can bug 2095 be fixed in D2? Or is it too late?

Not too late at all! And I just elevated the importance of the bug. Please vote. Andrei
Nov 27 2010
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Torarin Wrote:

 Static interfaces (same thing as c++ 0x's ditched concepts) seem very
 useful. Did you consider them at some point?

static interface seems consistent with C#, though, I think static class is misdesing by itself. I'd prefer template interface ISummable(T) { static T opAdd(T lh, T rh); }
Nov 26 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/27/10 1:18 CST, Kagamin wrote:
 Torarin Wrote:

 Static interfaces (same thing as c++ 0x's ditched concepts) seem very
 useful. Did you consider them at some point?

static interface seems consistent with C#, though, I think static class is misdesing by itself. I'd prefer template interface ISummable(T) { static T opAdd(T lh, T rh); }

We use template constraints for that kind of stuff. Andrei
Nov 27 2010
parent reply BLS <windevguy hotmail.de> writes:
On 27/11/2010 16:59, Torarin wrote:
 2010/11/27 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:
 We use template constraints for that kind of stuff.

 Andrei

Yes, and that's great, but is there a way to check whether a template argument matches a defined interface?

I could not resist.. We should have Implements! Luca has done some work on it.. but it does not compile anymore. However I think the intension is clear. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=101673
Nov 27 2010
next sibling parent BLS <windevguy hotmail.de> writes:
On 28/11/2010 00:19, Jonathan M Davis wrote:
 On Saturday 27 November 2010 14:59:09 BLS wrote:
 On 27/11/2010 16:59, Torarin wrote:
 2010/11/27 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:
 We use template constraints for that kind of stuff.

 Andrei

Yes, and that's great, but is there a way to check whether a template argument matches a defined interface?

I could not resist.. We should have Implements! Luca has done some work on it.. but it does not compile anymore. However I think the intension is clear. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&a rticle_id=101673

If you're checking whether it implements an interface, then : should work just like it does with classes. If you're checking whether it has the same functions that an interface requires, then you're not really using interfaces correctly. structs don't implement interfaces. Classes do that. So, either make it a class, or don't use interfaces. If you want to verify that a struct has particular functions needed for the template function in question, then just check whether calling them compiles ( e.g. __traits(compiles, foo.bar()) ). If you have a set of functions that are expected to be there (for instance, to verify that the given type is a certain type of range), then just create template which checks for each of the functions that are supposed to be there and use the template ( e.g. isForwardRange!T ). Interfaces and structs don't have anything to do with each other. - Jonathan M Davis

Thanks for taking the time to explain. I've copypasted. However, Given that dCollections enable me to change the underlaying algorithm (say I can replace the default RBTree with SkipList) In order to so that I have to fulfil some requirements. And now, I guess that is what I am talking about. I want a guarantee that my skiplist implementation fulfills the cursor (a structure) requirements. So now what is wrong with the contract from dCollections I am asking for. Please note that dCollections implements cursors as well as ranges. Bjoern
Nov 27 2010
prev sibling next sibling parent BLS <windevguy hotmail.de> writes:
On 28/11/2010 01:23, Torarin wrote:
 if (Implements!(Something, T))

 Thanks for the link, BLS, I'll see if I can make it work.

Keep us Informed!(About,This) Bjoern
Nov 27 2010
prev sibling next sibling parent reply Adam Burton <adz21c gmail.com> writes:
Jonathan M Davis wrote:

 On Saturday 27 November 2010 14:59:09 BLS wrote:
 On 27/11/2010 16:59, Torarin wrote:
 2010/11/27 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:
 We use template constraints for that kind of stuff.
 
 Andrei

Yes, and that's great, but is there a way to check whether a template argument matches a defined interface?

I could not resist.. We should have Implements! Luca has done some work on it.. but it does not compile anymore. However I think the intension is clear.


 rticle_id=101673

If you're checking whether it implements an interface, then : should work just like it does with classes. If you're checking whether it has the same functions that an interface requires, then you're not really using interfaces correctly. structs don't implement interfaces. Classes do that. So, either make it a class, or don't use interfaces. If you want to verify that a struct has particular functions needed for the template function in question, then just check whether calling them compiles ( e.g. __traits(compiles, foo.bar()) ). If you have a set of functions that are expected to be there (for instance, to verify that the given type is a certain type of range), then just create template which checks for each of the functions that are supposed to be there and use the template ( e.g. isForwardRange!T ). Interfaces and structs don't have anything to do with each other. - Jonathan M Davis

word for what it is. Structs and base types have a public interface. Contraints like isForwardRange are checking the public interface of the type passed too them. Seems to me Ds interfaces are more like types than interfaces (consider you can cast to an interface). Personally I think having an "implements" makes sense (that loops through the methods of an interface and checks the type has matching methods, not the same as having a class "implement" an interface which is more like inheritance). However as you say, that is not how interfaces in their current form are designed to be used so I understand why people disagree.
Nov 27 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-11-27 20:55:51 -0500, Adam Burton <adz21c gmail.com> said:

 Personally I think having an "implements" makes sense (that loops through
 the methods of an interface and checks the type has matching methods, not
 the same as having a class "implement" an interface which is more like
 inheritance). However as you say, that is not how interfaces in their
 current form are designed to be used so I understand why people disagree.

Well, if you consider the previously discussed 'adaptTo' function template, all types can be adapted to an interface (via a template-generated wrapper class). So "implements" for structs isn't too far off, as you can use the struct to implement the interface via 'adaptTo'. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Nov 27 2010
parent Adam Burton <adz21c gmail.com> writes:
Jonathan M Davis wrote:

 On Saturday 27 November 2010 19:40:09 Michel Fortin wrote:
 On 2010-11-27 20:55:51 -0500, Adam Burton <adz21c gmail.com> said:
 Personally I think having an "implements" makes sense (that loops
 through the methods of an interface and checks the type has matching
 methods, not the same as having a class "implement" an interface which
 is more like inheritance). However as you say, that is not how
 interfaces in their current form are designed to be used so I
 understand why people disagree.

Well, if you consider the previously discussed 'adaptTo' function template, all types can be adapted to an interface (via a template-generated wrapper class). So "implements" for structs isn't too far off, as you can use the struct to implement the interface via 'adaptTo'.

Except that 1, adaptTo!() is going to wrapping the struct in a class, so it's technically the class which implements the interface (even if it's just a wrapper).

 
 2. More importantly, now you have the added confusion of is it a class, a
 struct, or a struct wrapped by a class that you're dealing with? So,
 talking about implements can quickly become confusing.

reference semantics onto the type, but someone implementing a struct will have done so over a class for a good reason. Hence adaptTo can cause confusion.
 
 It quickly starts looking like we need new terms which are more precise if
 we want to have clear conversations on the matter.
 
 - Jonathan M Davis

collection of methods and properties that a type can implement (actually I prefer the conformsTo someone mentioned earlier). Where as in reality D has it more like a basic type of class that can be inherited and implment its abstract methods + properties. Constraints with templates actually model the idea of an interface far better, they check whether said Type conforms to the interface it expects and uses it. It doesn't force it to be class like, just a type with a set of certain methods. So you are truley "programming to an interface". D's interfaces make much more sense to me when I think of them as a purely abstract dataless class type.
Nov 28 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 27 November 2010 19:40:09 Michel Fortin wrote:
 On 2010-11-27 20:55:51 -0500, Adam Burton <adz21c gmail.com> said:
 Personally I think having an "implements" makes sense (that loops through
 the methods of an interface and checks the type has matching methods, not
 the same as having a class "implement" an interface which is more like
 inheritance). However as you say, that is not how interfaces in their
 current form are designed to be used so I understand why people disagree.

Well, if you consider the previously discussed 'adaptTo' function template, all types can be adapted to an interface (via a template-generated wrapper class). So "implements" for structs isn't too far off, as you can use the struct to implement the interface via 'adaptTo'.

Except that 1, adaptTo!() is going to wrapping the struct in a class, so it's technically the class which implements the interface (even if it's just a wrapper). 2. More importantly, now you have the added confusion of is it a class, a struct, or a struct wrapped by a class that you're dealing with? So, talking about implements can quickly become confusing. It quickly starts looking like we need new terms which are more precise if we want to have clear conversations on the matter. - Jonathan M Davis
Nov 27 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/27/10 7:55 PM, Adam Burton wrote:
 Jonathan M Davis wrote:

 On Saturday 27 November 2010 14:59:09 BLS wrote:
 On 27/11/2010 16:59, Torarin wrote:
 2010/11/27 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:
 We use template constraints for that kind of stuff.

 Andrei

Yes, and that's great, but is there a way to check whether a template argument matches a defined interface?

I could not resist.. We should have Implements! Luca has done some work on it.. but it does not compile anymore. However I think the intension is clear.


 rticle_id=101673

If you're checking whether it implements an interface, then : should work just like it does with classes. If you're checking whether it has the same functions that an interface requires, then you're not really using interfaces correctly. structs don't implement interfaces. Classes do that. So, either make it a class, or don't use interfaces. If you want to verify that a struct has particular functions needed for the template function in question, then just check whether calling them compiles ( e.g. __traits(compiles, foo.bar()) ). If you have a set of functions that are expected to be there (for instance, to verify that the given type is a certain type of range), then just create template which checks for each of the functions that are supposed to be there and use the template ( e.g. isForwardRange!T ). Interfaces and structs don't have anything to do with each other. - Jonathan M Davis

word for what it is. Structs and base types have a public interface. Contraints like isForwardRange are checking the public interface of the type passed too them. Seems to me Ds interfaces are more like types than interfaces (consider you can cast to an interface). Personally I think having an "implements" makes sense (that loops through the methods of an interface and checks the type has matching methods, not the same as having a class "implement" an interface which is more like inheritance). However as you say, that is not how interfaces in their current form are designed to be used so I understand why people disagree.

Walter and I discussed a number of times allowing structs to inherit interfaces. I even submitted an enhancement request once. Unfortunately, the feature wouldn't be a game-changer because interfaces are quite rigid - for example, you often want to enforce that a template defines a type. Before you know it, you need to add language to interfaces that makes them start looking like the stillborn C++ concepts. I think template constraints are a better solution. Andrei
Nov 28 2010
parent Adam Burton <adz21c gmail.com> writes:
Andrei Alexandrescu wrote:

 On 11/27/10 7:55 PM, Adam Burton wrote:
 Jonathan M Davis wrote:

 On Saturday 27 November 2010 14:59:09 BLS wrote:
 On 27/11/2010 16:59, Torarin wrote:
 2010/11/27 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:
 We use template constraints for that kind of stuff.

 Andrei

Yes, and that's great, but is there a way to check whether a template argument matches a defined interface?

I could not resist.. We should have Implements! Luca has done some work on it.. but it does not compile anymore. However I think the intension is clear.




 rticle_id=101673

If you're checking whether it implements an interface, then : should work just like it does with classes. If you're checking whether it has the same functions that an interface requires, then you're not really using interfaces correctly. structs don't implement interfaces. Classes do that. So, either make it a class, or don't use interfaces. If you want to verify that a struct has particular functions needed for the template function in question, then just check whether calling them compiles ( e.g. __traits(compiles, foo.bar()) ). If you have a set of functions that are expected to be there (for instance, to verify that the given type is a certain type of range), then just create template which checks for each of the functions that are supposed to be there and use the template ( e.g. isForwardRange!T ). Interfaces and structs don't have anything to do with each other. - Jonathan M Davis

word for what it is. Structs and base types have a public interface. Contraints like isForwardRange are checking the public interface of the type passed too them. Seems to me Ds interfaces are more like types than interfaces (consider you can cast to an interface). Personally I think having an "implements" makes sense (that loops through the methods of an interface and checks the type has matching methods, not the same as having a class "implement" an interface which is more like inheritance). However as you say, that is not how interfaces in their current form are designed to be used so I understand why people disagree.

Walter and I discussed a number of times allowing structs to inherit interfaces. I even submitted an enhancement request once. Unfortunately, the feature wouldn't be a game-changer because interfaces are quite rigid - for example, you often want to enforce that a template defines a type. Before you know it, you need to add language to interfaces that makes them start looking like the stillborn C++ concepts. I think template constraints are a better solution. Andrei

addition, just a convenience tenmplate function and change of terminology (which obviously couldn't happen due to TDPL). I just think having an implements template function adds convenience and readability. However I agree constraints model the idea of an interface better than interfaces/concepts. Most of the time I can see people expecting a Type with said selection of functions, so having an interface you can pass to implements helps for readability. As you say there are cases where this really doesn't model what you want well enough, therefore you can fall back to raw constraints which have the flexibility to do what you need.
Nov 28 2010
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Jonathan M Davis wrote:
 On Saturday 27 November 2010 14:59:09 BLS wrote:
 On 27/11/2010 16:59, Torarin wrote:
 2010/11/27 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:
 We use template constraints for that kind of stuff.

 Andrei




 argument matches a defined interface?

We should have Implements! Luca has done some work on it.. but it does not compile anymore. Howev=


 I think the intension is clear.
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=3Ddigitalm=


 rticle_id=3D101673

If you're checking whether it implements an interface, then : should wo=

 like it does with classes. If you're checking whether it has the same f=

 that an interface requires, then you're not really using interfaces cor=

 structs don't implement interfaces. Classes do that. So, either make it=

 or don't use interfaces. If you want to verify that a struct has partic=

 functions needed for the template function in question, then just check=

 calling them compiles ( e.g. __traits(compiles, foo.bar()) ). If you ha=

 of functions that are expected to be there (for instance, to verify tha=

 given type is a certain type of range), then just create template which=

 for each of the functions that are supposed to be there and use the tem=

 e.g. isForwardRange!T ). Interfaces and structs don't have anything to =

 each other.
=20

type. If you want to check the return and parameter types, you wind up with a very complex and ugly expression. This is very error prone. Look at the two examples below: Using __traits(compiles...): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D8<------------------------------ template isFooBar(T) { enum bool isFooBar =3D __traits (compiles, { T t; int arg; int r =3D t.foo (arg); }) && __traits (compiles, { T t; float arg; bool r =3D t.bar (arg); }); } template Test(T) if (isFooBar!T) ... ------------------------------>8=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Using a fictive "concept" keyword instead of "interface" to avoid confusions with true interfaces: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D8<------------------------------ concept FooBar { int foo (int); bool bar (float); } template Test(T) if (is!FooBar (T)) ... ------------------------------>8=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The second one is clearly much easier to write and (especially) easier to read, which means: - It is faster to write; - It will contain a lot fewer errors and bugs (especially once you get into more complex concepts); - It is immediately self-documenting. Now, it might be possible to do this purely as a library with the current language if we are willing to re-use the "interface" keyword to define the concepts. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Nov 28 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Jonathan M Davis wrote:
 A clearer way to create such template constraints would definitely be n=

 aside from the fact that I'd absolutely hate to see interfaces be confl=

 template constraints in this manner, you'd need a way to deal with the =

 the parameters and return types for such functions are frequently depen=

 the type that the template is being instantiated with. A concept as you=

 it would have to somehow take templated types into account in a way tha=

 interfaces can't. For instance, you could never define an interface whi=

 a forward range like isForwardRange!() does because the interface would=

 properly templatized.
=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D8<------------------------------ concept FooBar(U) { int foo (int); bool bar (U); } template Test(T, U) if (is!(FooBar!U, T)) ... ------------------------------>8=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This already works with class and interface templates... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Nov 28 2010
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Jonathan M Davis wrote:
 On Sunday, November 28, 2010 04:43:47 J=C3=A9r=C3=B4me M. Berger wrote:=

 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


 concept FooBar(U)
 {
    int  foo (int);
    bool bar (U);
 }

 template Test(T, U) if (is!(FooBar!U, T)) ...
 ------------------------------>8=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


 	This already works with class and interface templates...

That may work. I was thinking of a verifying against a concrete interfa=

 which _wouldn't_ work with templates. I probably didn't think of this b=

 mixing templates and interfaces or classes is generally a bad idea in D=

 template functions can't be virtual.
=20

I describe here has *nothing* to do with interfaces as they currently exist in D (although a library solution could be done using interfaces if nothing else is done). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Nov 29 2010
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2010-11-27 at 05:51 +0100, Torarin wrote:
 Static interfaces (same thing as c++ 0x's ditched concepts) seem very
 useful. Did you consider them at some point?

Concepts didn't make C++0x but I am sure Bjarne will bring a revised proposal back to the table. If the C++ committee do what the Fortran committee do, then there could be an intermediate standard within the usual 10 year cycle. So assuming C++0x is actually ratified, then 4 years later concepts could get into the language. I was at a workshop end of last year that was looking at various issues in C++ and ML's (probably OCaml's?) ability to handle all this sort of stuff for many years got Bjarne convinced to revisit concepts and create a revised proposal. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Nov 27 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/27/10 4:18 CST, Russel Winder wrote:
 On Sat, 2010-11-27 at 05:51 +0100, Torarin wrote:
 Static interfaces (same thing as c++ 0x's ditched concepts) seem very
 useful. Did you consider them at some point?

Concepts didn't make C++0x but I am sure Bjarne will bring a revised proposal back to the table. If the C++ committee do what the Fortran committee do, then there could be an intermediate standard within the usual 10 year cycle. So assuming C++0x is actually ratified, then 4 years later concepts could get into the language. I was at a workshop end of last year that was looking at various issues in C++ and ML's (probably OCaml's?) ability to handle all this sort of stuff for many years got Bjarne convinced to revisit concepts and create a revised proposal.

I sure hope they learn from D's experience with template constraints, which has been overwhelmingly positive. Andrei
Nov 27 2010
prev sibling next sibling parent Torarin <torarind gmail.com> writes:
2010/11/27 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 We use template constraints for that kind of stuff.

 Andrei

Yes, and that's great, but is there a way to check whether a template argument matches a defined interface?
Nov 27 2010
prev sibling next sibling parent Torarin <torarind gmail.com> writes:
2010/11/28 Michel Fortin <michel.fortin michelf.com>:
 Well, if you consider the previously discussed 'adaptTo' function template,
 all types can be adapted to an interface (via a template-generated wrapper
 class). So "implements" for structs isn't too far off, as you can use the
 struct to implement the interface via 'adaptTo'.

Actually, adaptTo already uses such a template internally. So I would suggest to just add this: template conformsTo(T, Interfaces...) { enum conformsTo = AdaptTo!Interfaces.hasRequiredMethods!T; }
Nov 27 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 27 Nov 2010 10:59:42 -0500, Torarin <torarind gmail.com> wrote:

 2010/11/27 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 We use template constraints for that kind of stuff.

 Andrei

Yes, and that's great, but is there a way to check whether a template argument matches a defined interface?

We have stuff like isInputRange!R. It's exactly what you want, but you have to do a bit more work. I would expect in about 1-2 days some template guru will come up with: implements!(T, U) which does all the boilerplate work of trying to see if U can be substituted anywhere T is used. -Steve
Nov 29 2010
prev sibling next sibling parent Torarin <torarind gmail.com> writes:
Static interfaces (same thing as c++ 0x's ditched concepts) seem very
useful. Did you consider them at some point?

Torarin

2010/11/27 Walter Bright <newshound2 digitalmars.com>:
 Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

A summary for those who don't want to sit through it: http://news.ycombinator.com/item?id=1942859

Nov 26 2010
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:

 http://oredev.org/2010/sessions/c-s-greatest-mistakes
 
 Andrei

I don't get these "programming videos" things. They look totally incoherent. Video in programming is like mud in art.
Nov 26 2010
parent Kagamin <spam here.lot> writes:
Kagamin Wrote:

 Video in programming is like mud in art.

Or like elephant in a kitchen... :-/
Nov 26 2010
prev sibling next sibling parent j <a a.com> writes:
I just hate how you can call IList.Clear on an array in C#, but it doesn't do
what it is supposed to (it doesn't change element count, it just sets all
elements to some default value).
Nov 27 2010
prev sibling next sibling parent Roman Ivanov <isroman.DEL ETE.km.ru> writes:
On 11/26/2010 10:27 PM, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes
 
 Andrei

The static interfaces the presenter speaks about make sense, but they are a kind of a hack at the same time. To me it seems that the two underlying problems are: 1. Classes with static methods and attributes should behave more like normal objects. (WE want to constrain them by interfaces, pass to methods, maybe even use inheritance.) 2. Constructors should behave more like static methods. (Again, we want to be able to reason about them inside interfaces.) For example: class DynamicGetter : IGetter{ int getValue(){ } } static class StaticGetter : IGetter{ //doesn't work, but probably should static int getValue(){ } } SomeObject.someMethod(new Dynamic()); //this is allowed SomeObject.someMethod(StaticGetter); //this is not allowed, why? Classes can contain static data and methods, so why they behave so drastically different from normal objects?
Nov 27 2010
prev sibling next sibling parent reply BLS <windevguy hotmail.de> writes:
On 27/11/2010 04:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

Frankly said, I am a bit nagged by your overoptimistic D view. From my point of view it is opportune to encourage people to use D2 for real world applications. We (our company) having a 20K+ customer base are not able (and willing) to use D instead of C#, except for tiny in-house projects. why > database, gui, xml, just to name the top 3 issues. So .. What about an "where C# shines and D sucks" article. Let us start with LINQ in D, or do you prefer to talk about phobos collections ? Bjoern ps don;t get me wrong. I like D.
Nov 27 2010
next sibling parent reply Roman Ivanov <isroman.DEL ETE.km.ru> writes:
On 11/27/2010 2:49 PM, BLS wrote:
 On 27/11/2010 04:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

Frankly said, I am a bit nagged by your overoptimistic D view. From my point of view it is opportune to encourage people to use D2 for real world applications. We (our company) having a 20K+ customer base are not able (and willing) to use D instead of C#, except for tiny in-house projects. why > database, gui, xml, just to name the top 3 issues.

Out of curiosity, what kind of XML support would you need?
 So .. What about an "where C#  shines and D sucks" article. Let us start
 with LINQ in D, or do you prefer to talk about phobos collections ?

Is something like LINQ possible in D?
Nov 27 2010
parent reply BLS <windevguy hotmail.de> writes:
On 27/11/2010 20:53, Roman Ivanov wrote:
 On 11/27/2010 2:49 PM, BLS wrote:
 On 27/11/2010 04:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

Frankly said, I am a bit nagged by your overoptimistic D view. From my point of view it is opportune to encourage people to use D2 for real world applications. We (our company) having a 20K+ customer base are not able (and willing) to use D instead of C#, except for tiny in-house projects. why> database, gui, xml, just to name the top 3 issues.

Out of curiosity, what kind of XML support would you need?

From Setup storage to WSDL to Restful services. (But it is almost about online ordering of material)
 So .. What about an "where C#  shines and D sucks" article. Let us start
 with LINQ in D, or do you prefer to talk about phobos collections ?

Is something like LINQ possible in D?

I don't think so. (ATM, several people have tried by using string mixins) But I can imagine at least one (imo) smart solution. Enable compiler plug-in's so that you can write .. void ExecSQLQuery() DataTable dt = new DataTable(); SQL92{ /*like asm {} */ dt = SELECT * FROM Customer WHERE IsPotentialClient = 1; } } //which translates into D code (the D lexer/parser unit calls the D2 SQL92 Translator generator which generated this D source) import SQL92 dt = db.Select("SELECT * FROM Customer WHERE PotentialClient = 1"); This translation feature could be generic.. we can create a translator based on Annotated EBNF In -> Annotated EBNF out In fact I've created a tool (in Java) to translate SQL scripts. Firebird to MSSQL respective PosgreSQL. Hope this gives you an idea.. :) Bjoern
Nov 27 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"BLS" <windevguy hotmail.de> wrote in message 
news:icrqfl$1ado$1 digitalmars.com...
 On 27/11/2010 20:53, Roman Ivanov wrote:
 On 11/27/2010 2:49 PM, BLS wrote:
 On 27/11/2010 04:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

Frankly said, I am a bit nagged by your overoptimistic D view. From my point of view it is opportune to encourage people to use D2 for real world applications. We (our company) having a 20K+ customer base are not able (and willing) to use D instead of C#, except for tiny in-house projects. why> database, gui, xml, just to name the top 3 issues.

Out of curiosity, what kind of XML support would you need?

From Setup storage to WSDL to Restful services. (But it is almost about online ordering of material)
 So .. What about an "where C#  shines and D sucks" article. Let us start
 with LINQ in D, or do you prefer to talk about phobos collections ?

Is something like LINQ possible in D?

I don't think so. (ATM, several people have tried by using string mixins) But I can imagine at least one (imo) smart solution. Enable compiler plug-in's so that you can write .. void ExecSQLQuery() DataTable dt = new DataTable(); SQL92{ /*like asm {} */ dt = SELECT * FROM Customer WHERE IsPotentialClient = 1; } } //which translates into D code (the D lexer/parser unit calls the D2 SQL92 Translator generator which generated this D source) import SQL92 dt = db.Select("SELECT * FROM Customer WHERE PotentialClient = 1"); This translation feature could be generic.. we can create a translator based on Annotated EBNF In -> Annotated EBNF out In fact I've created a tool (in Java) to translate SQL scripts. Firebird to MSSQL respective PosgreSQL. Hope this gives you an idea.. :) Bjoern

I haven't actually used LINQ, but I've never understood the appeal of it versus an object API that gets rid of SQL in user code entirely.
Nov 28 2010
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky wrote:
 I haven't actually used LINQ, but I've never understood the
 appeal of it versus an object API that gets rid of SQL in
 user code entirely.

I'm on the other side... why bother getting rid of SQL at all? Well, I can see the appeal, but I've never seen a system that lived up to the promises. Avoiding writing SQL tends to be more trouble than it's worth if you ask me.
Nov 28 2010
parent reply Roman Ivanov <isroman.DEL ETE.km.ru> writes:
On 11/28/2010 1:25 PM, Adam D. Ruppe wrote:
 Nick Sabalausky wrote:
 I haven't actually used LINQ, but I've never understood the
 appeal of it versus an object API that gets rid of SQL in
 user code entirely.

I'm on the other side... why bother getting rid of SQL at all? Well, I can see the appeal, but I've never seen a system that lived up to the promises. Avoiding writing SQL tends to be more trouble than it's worth if you ask me.

The trouble is that people try to get rid of SQL in their code, while using SQL-driven databases. The resulting systems are still limited by SQL, because in the end that's what gets run.
Nov 28 2010
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 28/11/2010 21:35, Roman Ivanov wrote:
 On 11/28/2010 1:25 PM, Adam D. Ruppe wrote:
 Nick Sabalausky wrote:
 I haven't actually used LINQ, but I've never understood the
 appeal of it versus an object API that gets rid of SQL in
 user code entirely.

I'm on the other side... why bother getting rid of SQL at all? Well, I can see the appeal, but I've never seen a system that lived up to the promises. Avoiding writing SQL tends to be more trouble than it's worth if you ask me.

The trouble is that people try to get rid of SQL in their code, while using SQL-driven databases. The resulting systems are still limited by SQL, because in the end that's what gets run.

Moreover, if the application is running on a different machine from the database, having an object API instead of SQL to do the processing can slow things down considerably. The company I worked for until recently had for its task management system an Access database stored on the fileserver. That way, all data processing happens on the client side - so when working from home and accessing it through VPN, it would be unbearably slow. (And before you ask, yes we did have Remote Desktop, but something about licensing meant that we couldn't use any of the Office apps through it.) If only it had been done as a server-client database app just like all the other software we developed.... Stewart.
Nov 28 2010
prev sibling parent Roman Ivanov <isroman.DEL ETE.km.ru> writes:
On 11/28/2010 1:19 PM, Nick Sabalausky wrote:
 "BLS" <windevguy hotmail.de> wrote in message 
 news:icrqfl$1ado$1 digitalmars.com...
 On 27/11/2010 20:53, Roman Ivanov wrote:
 On 11/27/2010 2:49 PM, BLS wrote:
 On 27/11/2010 04:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

Frankly said, I am a bit nagged by your overoptimistic D view. From my point of view it is opportune to encourage people to use D2 for real world applications. We (our company) having a 20K+ customer base are not able (and willing) to use D instead of C#, except for tiny in-house projects. why> database, gui, xml, just to name the top 3 issues.

Out of curiosity, what kind of XML support would you need?

From Setup storage to WSDL to Restful services. (But it is almost about online ordering of material)
 So .. What about an "where C#  shines and D sucks" article. Let us start
 with LINQ in D, or do you prefer to talk about phobos collections ?

Is something like LINQ possible in D?

I don't think so. (ATM, several people have tried by using string mixins) But I can imagine at least one (imo) smart solution. Enable compiler plug-in's so that you can write .. void ExecSQLQuery() DataTable dt = new DataTable(); SQL92{ /*like asm {} */ dt = SELECT * FROM Customer WHERE IsPotentialClient = 1; } } //which translates into D code (the D lexer/parser unit calls the D2 SQL92 Translator generator which generated this D source) import SQL92 dt = db.Select("SELECT * FROM Customer WHERE PotentialClient = 1"); This translation feature could be generic.. we can create a translator based on Annotated EBNF In -> Annotated EBNF out In fact I've created a tool (in Java) to translate SQL scripts. Firebird to MSSQL respective PosgreSQL. Hope this gives you an idea.. :) Bjoern

I haven't actually used LINQ, but I've never understood the appeal of it versus an object API that gets rid of SQL in user code entirely.

LINQ _is_ an object API. The query-like syntax is just a misfeature. But it's not _just_ an object API, because it translates statement into expression trees, which can be analyzed and used to generate different code or code in a different language. Let's say you have a list of objects and need to get only the ones whose name starts with "D". You can express the predicate via lambda expression: x => x.Name.Length > 0 && x.Name[0] == 'D'. Simple, right? Here is the problem. You can apply this expression to every object in the list, but you don't always want to. What if it's a database table with 10000 records? You don't want to retrieve all those records, especially if there is already an index. LINQ allows to analyze the lambda function and generate an appropriate SQL query. At lest that how I understand it.
Nov 28 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/27/10 13:49 CST, BLS wrote:
 On 27/11/2010 04:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

Frankly said, I am a bit nagged by your overoptimistic D view. From my point of view it is opportune to encourage people to use D2 for real world applications. We (our company) having a 20K+ customer base are not able (and willing) to use D instead of C#, except for tiny in-house projects. why > database, gui, xml, just to name the top 3 issues. So .. What about an "where C# shines and D sucks" article. Let us start with LINQ in D, or do you prefer to talk about phobos collections ? Bjoern ps don;t get me wrong. I like D.

I just thought it would be an interesting watch/read. I have sent the "one year of Go" link too, though it was to a large extent complimentary of Go. Andrei
Nov 27 2010
parent reply BLS <windevguy hotmail.de> writes:
On 27/11/2010 21:28, Andrei Alexandrescu wrote:
 On 11/27/10 13:49 CST, BLS wrote:
 On 27/11/2010 04:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

Frankly said, I am a bit nagged by your overoptimistic D view. From my point of view it is opportune to encourage people to use D2 for real world applications. We (our company) having a 20K+ customer base are not able (and willing) to use D instead of C#, except for tiny in-house projects. why > database, gui, xml, just to name the top 3 issues. So .. What about an "where C# shines and D sucks" article. Let us start with LINQ in D, or do you prefer to talk about phobos collections ? Bjoern ps don;t get me wrong. I like D.

I just thought it would be an interesting watch/read. I have sent the "one year of Go" link too, though it was to a large extent complimentary of Go. Andrei

Would be nice if you take 7 seconds to read and comment my previous msg reg. Compiler plug ins Bjoern
Nov 27 2010
parent reply BLS <windevguy hotmail.de> writes:
Hi Andrej,
I was not aware that GCC has plugin support. (being a Windows guy, well 
almost)
..an interesting EBNF in -> EBNF out ->Translator read is ..

http://www.tools.vlampe.de/depot4/Depot4.html

Bjoern


On 27/11/2010 21:58, Andrej Mitrovic wrote:
 GCC has plugins, right? I think I've read that somewhere.. so maybe
 GDC will have that as well some day..

Nov 27 2010
parent reply Kagamin <spam here.lot> writes:
BLS Wrote:

 Hi Andrej,
 I was not aware that GCC has plugin support. (being a Windows guy, well 
 almost)
 ..an interesting EBNF in -> EBNF out ->Translator read is ..
 
 http://www.tools.vlampe.de/depot4/Depot4.html
 
 Bjoern

There's also xoc http://pdos.csail.mit.edu/xoc/
Nov 27 2010
parent reply BLS <windevguy hotmail.de> writes:
On 27/11/2010 23:47, Kagamin wrote:
 BLS Wrote:

 Hi Andrej,
 I was not aware that GCC has plugin support. (being a Windows guy, well
 almost)
 ..an interesting EBNF in ->  EBNF out ->Translator read is ..

 http://www.tools.vlampe.de/depot4/Depot4.html

 Bjoern

There's also xoc http://pdos.csail.mit.edu/xoc/

Thanks for the link. I am watching xoc for quite a while now. In my humble opinion xoc wants a bit tooo much. what i am trying to archive is based on .. You can describe EBNF (E) in EBNF. Writing an EBNF parser (E1) is simple. Generating parser D source code based on (E1) and target language transformation(E2) In other words whenever the lwxer finds LanguageX{ call the adequate 2D translator mixin the generated D code an carry on, as usual) /Given a spooky PASCAL TO Kinda D Translator-EBNF:/ Differnce to standard EBNF is EBNFin ->EBNFout program = block '.' -> 'import std.io\n' block_ . block = ['VAR' ident {',' ident[i]} ';'] 'BEGIN' statement {/..c/';' statement[i] } 'END' -> ['int ' ident_ {',' ident_[i]} ';\n'] 'main() \n{\n' statement_ {/..c/ '\n' statement_[i] } '}\n'. statement = 'WRITE' expression | 'READ' ident| 'BEGIN' statement[1] {';' statement[i+1] } 'END' | 'IF' expression 'THEN' st:statement ['ELSE' ste:statement] | 'WHILE' expression 'DO' st:statement | ident ':=' expression | -> 'printf("%d",' expression_ ');' | 'scanf("%d", &' ident_ ');' | '{' {/..N+1/ statement_[i] '\n' } '}' | 'if (' expression_ ') ' st_ ['else ' ste_ ]| 'while (' expression_ ') ' st_ | ident_ '=' expression_ ';'| . expression = simpleExpr [('='|'<='|'>='|'<>'|'<'|'>') sE: simpleExpr ] -> simpleExpr_ [('=='|'<='|'>='|'!='|'<'|'>') sE_ ]. simpleExpr = VAR op: FLEX OF INT; ['+'|'-'] term {(/op[i]/'+'|'-'|'OR') term[i] } -> ['+'|'-'] term_ {(/op[i]/'+'|'-'|'||') term_[i] }. term = VAR op: FLEX OF INT; factor {(/op[i]/'*'|'DIV'|'AND') f2:factor[i]} -> factor_ {(/op[i]/ '*'|'/'|'&&') f2_[i]}. factor = num | '(' expression ')'| 'NOT' factor | ident -> num_ |'(' expression_ ')'|'!' factor_ | ident_ . /Will translate spooky source Pascal into Cish target source/ SOURCE TARGET VAR X, Y, H, GGT; import std.io BEGIN int X,Y,H,GGT; READ X; READ Y; main() WHILE X<>0 DO { BEGIN scanf("%d", &X); IF X<Y THEN BEGIN scanf("%d", &Y); H:= X; X:= Y; Y:= H while (X!=0) {if (X<Y) {H=X; END; X=Y; X:= X-Y; Y=H; WHILE X<Y DO X:= X-Y } X:= X-Y X=X-Y; END; while (X<Y) X=X-Y; GGT:= Y; WRITE GGT } END. GGT=Y; printf("%d",GGT);} So in order to create a Tool which is able to create an SQL2D Translator (as D2 DLL/so) just by descrining Source an Target EBNF could be a great help.. Calling such an ready to use Translator whenever the standard D Lexer finds SQL{ or Pascal{ or Go { should not be that difficult.
Nov 27 2010
parent "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"BLS" <windevguy hotmail.de> ?????????/?????????? ? 
???????:ics611$22s8$1 digitalmars.com...
 So in order to create a Tool which is able to create an SQL2D Translator 
 (as D2 DLL/so) just by descrining Source an Target EBNF could be a great 
 help.. Calling such an ready to use Translator whenever the standard D 
 Lexer finds SQL{  or Pascal{ or Go { should not be that difficult.

Your idea about compiler plugins is really Amazing, it can be even created as external tool, e.g. preprocessor, which scans D code for CommandX {command_str} - runs corresponding plugin, and changes this CommandX{...} to generated output string. If plugin returns error-code it changes CommandX {..} to assert (0, plugin_error_string); Oh, some problem can appear when different plugins define same CommandX
Nov 28 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
GCC has plugins, right? I think I've read that somewhere.. so maybe
GDC will have that as well some day..

On 11/27/10, BLS <windevguy hotmail.de> wrote:
 On 27/11/2010 21:28, Andrei Alexandrescu wrote:
 On 11/27/10 13:49 CST, BLS wrote:
 On 27/11/2010 04:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

Frankly said, I am a bit nagged by your overoptimistic D view. From my point of view it is opportune to encourage people to use D2 for real world applications. We (our company) having a 20K+ customer base are not able (and willing) to use D instead of C#, except for tiny in-house projects. why > database, gui, xml, just to name the top 3 issues. So .. What about an "where C# shines and D sucks" article. Let us start with LINQ in D, or do you prefer to talk about phobos collections ? Bjoern ps don;t get me wrong. I like D.

I just thought it would be an interesting watch/read. I have sent the "one year of Go" link too, though it was to a large extent complimentary of Go. Andrei

Would be nice if you take 7 seconds to read and comment my previous msg reg. Compiler plug ins Bjoern

Nov 27 2010
prev sibling next sibling parent reply bearophobic <notbear cave.net> writes:
BLS Wrote:

 On 27/11/2010 04:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

Frankly said, I am a bit nagged by your overoptimistic D view. From my point of view it is opportune to encourage people to use D2 for real world applications. We (our company) having a 20K+ customer base are not able (and willing) to use D instead of C#, except for tiny in-house projects. why > database, gui, xml, just to name the top 3 issues. So .. What about an "where C# shines and D sucks" article. Let us start with LINQ in D, or do you prefer to talk about phobos collections ? Bjoern ps don;t get me wrong. I like D.

Critical articles of D damage our reputation. The internet archives and caches store all damaging content. Would be better if all fans of D modified their earlier critical public posts when the features have been fixed to minimize the damage. Development discussion board (bugzilla) should be totally private to avoid bad FUD from spreading elsewhere. We could make the system generate unique URL ids for all links to reveal the identity of those who spread FUD about D. Walter Bright could filter the archives by grepping away "D sucks" news articles. We should only announce good news, nothing bad. This helps get better impression and more participants in development and avoid politics. This way the features you want get fixed faster. Bye, bearophobic
Nov 27 2010
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
bearophobic schrieb:
 BLS Wrote:
 
 On 27/11/2010 04:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

From my point of view it is opportune to encourage people to use D2 for real world applications. We (our company) having a 20K+ customer base are not able (and willing) to use D instead of C#, except for tiny in-house projects. why > database, gui, xml, just to name the top 3 issues. So .. What about an "where C# shines and D sucks" article. Let us start with LINQ in D, or do you prefer to talk about phobos collections ? Bjoern ps don;t get me wrong. I like D.

Critical articles of D damage our reputation. The internet archives and caches store all damaging content. Would be better if all fans of D modified their earlier critical public posts when the features have been fixed to minimize the damage. Development discussion board (bugzilla) should be totally private to avoid bad FUD from spreading elsewhere. We could make the system generate unique URL ids for all links to reveal the identity of those who spread FUD about D. Walter Bright could filter the archives by grepping away "D sucks" news articles. We should only announce good news, nothing bad. This helps get better impression and more participants in development and avoid politics. This way the features you want get fixed faster. Bye, bearophobic

Yeah right censor criticism and cripple old forum posts (thus destroying all context), that'll earn us great reputation.
Nov 27 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/27/10 15:22 CST, bearophobic wrote:
 BLS Wrote:

 On 27/11/2010 04:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

Frankly said, I am a bit nagged by your overoptimistic D view. From my point of view it is opportune to encourage people to use D2 for real world applications. We (our company) having a 20K+ customer base are not able (and willing) to use D instead of C#, except for tiny in-house projects. why> database, gui, xml, just to name the top 3 issues. So .. What about an "where C# shines and D sucks" article. Let us start with LINQ in D, or do you prefer to talk about phobos collections ? Bjoern ps don;t get me wrong. I like D.

Critical articles of D damage our reputation. The internet archives and caches store all damaging content. Would be better if all fans of D modified their earlier critical public posts when the features have been fixed to minimize the damage. Development discussion board (bugzilla) should be totally private to avoid bad FUD from spreading elsewhere. We could make the system generate unique URL ids for all links to reveal the identity of those who spread FUD about D. Walter Bright could filter the archives by grepping away "D sucks" news articles. We should only announce good news, nothing bad. This helps get better impression and more participants in development and avoid politics. This way the features you want get fixed faster. Bye, bearophobic

That would be exaggerated, by a lot. I'm not even sure whether you're being ironic. Anyway, by and large, if the likes of Walter, Don, Sean, and some other contributors including myself weren't the nuts who believe in this language, something would be wrong. Clearly D's perception has a trailing edge of instability and political strife. Perception is a slow moving quantity so I'm patient about perception getting better while of course we work hard on improving things. Bjoern, just like you, I find the notion of compiler plugins very attractive but I have to say that we have more pressing concerns at this time. We can't spread ourselves all too thin. Andrei
Nov 27 2010
parent BLS <windevguy hotmail.de> writes:
On 27/11/2010 22:38, Andrei Alexandrescu wrote:
 Bjoern, just like you, I find the notion of compiler plugins very
 attractive but I have to say that we have more pressing concerns at this
 time. We can't spread ourselves all too thin.

Well this is good enough (tm) to me :) I just hope this feature will not be out of sight during the D2 "hard core development time" . I am pretty sure that we can pulverize LINQ, like you have done it with Boost algorithm" . It is maybe just 4 us. But database/gui support is most important CYA Mate
Nov 27 2010
prev sibling parent reply BLS <windevguy hotmail.de> writes:
On 27/11/2010 22:22, bearophobic wrote:
 Critical articles of D damage our reputation. The internet archives and

So bearophobic == bearophile ? well, NO it is definitely not my intention to produce unnecessary noise. Instead (like bearophile) I want a better D2. and (erm) I think this is a valuable suggestion.. Enable compiler plug-in's so that you can write .. void ExecSQLQuery() DataTable dt = new DataTable(); SQL92{ /*like asm {} */ dt = SELECT * FROM Customer WHERE IsPotentialClient = 1; } } //The D lexer/parser unit calls the D2 SQL92 Translator on finding SQL92{ which emits this D code. import SQL92 dt = db.ExecuteQuery("SELECT * FROM Customer WHERE PotentialClient = 1"); I am not talking about embedded SQL, instead I am thinking about a smart way to embed 4GLs (LISP/PROLOG/ERLANG) into D. and as shown within the example. using the D scope.
Nov 27 2010
parent reply BLS <windevguy hotmail.de> writes:
On 27/11/2010 23:16, spir wrote:
 Maybe the example does not show what you actually mean, but I do not see any
advantage. Version plain D is close to perfect, obvious, direct; version
embedded DSL just adds noise (and work for implementing the feature, and work
for a precompiler or whatever...).

1-How do you implement LINQ in D ? 2-Having such an compiler plugin architecture, will enable you f.i to seamless use Go, Lisp whatever within D. 3-Even if these plugins (please note > more than one) are just for SQL, you got database access for free. 4- I am using such an EBNF driven tool (almost written by me) to translate SQL scripts. // Create a new db from firebird to mssql.. including stored procedures, triggers etc. So sorry Denis, I know what I am talking about. Bjoern
Nov 27 2010
parent Roman Ivanov <isroman.DEL ETE.km.ru> writes:
On 11/27/2010 5:32 PM, BLS wrote:
 On 27/11/2010 23:16, spir wrote:
 Maybe the example does not show what you actually mean, but I do not
 see any advantage. Version plain D is close to perfect, obvious,
 direct; version embedded DSL just adds noise (and work for
 implementing the feature, and work for a precompiler or whatever...).

1-How do you implement LINQ in D ?

AFAIK, LINQ is _not_ SQL embedded into C# or VB. It's a mechanism that allows C# to examine expressions (written in C#, as strange as they might look) and translate them to SQL (or whatever). LINQ can take two forms. First: var query = from s in names where s.Length == 5 orderby s select s.ToUpper(); Second: var query = names.where(s => s.Length == 5) .orderby(s => s) .select(s => s.ToUpper()); They are semantically identical, but I like the second syntax much more, because it uses existing language features, works with auto-completion and is much more readable in complex cases. To support something like that a language needs to have tools for introspection of its own code.
 2-Having such an compiler plugin architecture, will enable you f.i to
 seamless use Go, Lisp whatever  within  D.
 
 3-Even if these plugins (please note > more than one) are just for SQL,
 you got database access for free.

LINQ for databases is a bit overrated. Writing real SQL queries is often simpler. LINQ query generator does some optimizations, but it also screws up in some cases. LINQ to objects is a different story, because it allows for much nicer declarative syntax to do mapping and projections.
 4- I am using such an EBNF driven tool (almost written by me) to
 translate SQL scripts. // Create a new db from firebird to mssql..
 including stored procedures, triggers etc.
 
 So sorry Denis, I know what I am talking about.
 Bjoern

Nov 28 2010
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On Sat, 27 Nov 2010 22:45:28 +0100
BLS <windevguy hotmail.de> wrote:

 [...]
 Enable compiler plug-in's so that you can write ..
=20
 void ExecSQLQuery()
    DataTable dt =3D new DataTable();
=20
    SQL92{ /*like asm {} */
      dt =3D SELECT * FROM Customer WHERE IsPotentialClient =3D 1;
    }
=20
 }
 //The D lexer/parser unit calls the D2 SQL92 Translator on finding=20
 SQL92{ which emits this D code.
=20
    import SQL92
    dt =3D db.ExecuteQuery("SELECT * FROM Customer WHERE PotentialClient =

=20
 I am not talking about embedded SQL, instead I am thinking about a smart=

 way to embed 4GLs (LISP/PROLOG/ERLANG) into D. and as shown within the=20
 example. using the D scope.

Maybe the example does not show what you actually mean, but I do not see an= y advantage. Version plain D is close to perfect, obvious, direct; version = embedded DSL just adds noise (and work for implementing the feature, and wo= rk for a precompiler or whatever...). Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Nov 27 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2010-11-28 at 15:57 -0500, Roman Ivanov wrote:
[ . . . ]
 AFAIK, LINQ is _not_ SQL embedded into C# or VB. It's a mechanism that
 allows C# to examine expressions (written in C#, as strange as they
 might look) and translate them to SQL (or whatever).

I have no idea how LINQ is realized but I know what happens in Groovy (and Python).
 LINQ can take two forms.
=20
 First:
 var query =3D from s in names
  where s.Length =3D=3D 5
  orderby s
  select s.ToUpper();
=20
 Second:
 var query =3D names.where(s =3D> s.Length =3D=3D 5)
  .orderby(s =3D> s)
  .select(s =3D> s.ToUpper());
=20
 They are semantically identical, but I like the second syntax much more,
 because it uses existing language features, works with auto-completion
 and is much more readable in complex cases.

Actually I prefer the former exactly because it is not an attempt to do a DSL by suffering the constraints of the language parser.
 To support something like that a language needs to have tools for
 introspection of its own code.

Yes, and this is why Groovy, Python, etc. are good at this sort of stuff and C, C++, Fortran, D, Go, etc., are generally less good at it. Basically this is one of the benefits of a full meta-object protocol. Something you really don't want in performance code.
 2-Having such an compiler plugin architecture, will enable you f.i to
 seamless use Go, Lisp whatever  within  D.
=20
 3-Even if these plugins (please note > more than one) are just for SQL,
 you got database access for free.

LINQ for databases is a bit overrated. Writing real SQL queries is often simpler. LINQ query generator does some optimizations, but it also screws up in some cases. LINQ to objects is a different story, because it allows for much nicer declarative syntax to do mapping and projections=

The experience in the Groovy/Java community is that using a DSL in Groovy rather than faffing around with strings and SQL directly, makes this a lot faster of production, with fewer bugs. This is anecdotal evidence only though so it may just be a perception thing rather than a real effect.
 4- I am using such an EBNF driven tool (almost written by me) to
 translate SQL scripts. // Create a new db from firebird to mssql..
 including stored procedures, triggers etc.
=20
 So sorry Denis, I know what I am talking about.
 Bjoern


--=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Nov 29 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2010-11-28 at 16:23 -0500, Roman Ivanov wrote:
[ . . . ]
 LINQ _is_ an object API. The query-like syntax is just a misfeature.

or desirable and useful feature!
 But it's not _just_ an object API, because it translates statement into
 expression trees, which can be analyzed and used to generate different
 code or code in a different language.
=20
 Let's say you have a list of objects and need to get only the ones whose
 name starts with "D". You can express the predicate via lambda
 expression: x =3D> x.Name.Length > 0 && x.Name[0] =3D=3D 'D'. Simple, rig=

 Here is the problem. You can apply this expression to every object in
 the list, but you don't always want to. What if it's a database table
 with 10000 records? You don't want to retrieve all those records,
 especially if there is already an index. LINQ allows to analyze the
 lambda function and generate an appropriate SQL query. At lest that how
 I understand it.

This is exactly how things are done in Groovy using builders. Because of the met-object protocol the DSL for interacting with SQL is a tree builder. The built query gets issued as needed. The fact that you have an incomplete query just means that the query is incomplete not that the idea of having a sane language-based DSL instead of having to build SQL queries with string manipulation is wrong. Surely using language features to build a query in the knowledge of the equivalent of well-formedness and validity is better than using string manipulation and hoping for the best. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Nov 29 2010
prev sibling next sibling parent so <so so.do> writes:
On Sat, 27 Nov 2010 21:49:03 +0200, BLS <windevguy hotmail.de> wrote:

 On 27/11/2010 04:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

Frankly said, I am a bit nagged by your overoptimistic D view. From my point of view it is opportune to encourage people to use D2 for real world applications. We (our company) having a 20K+ customer base are not able (and willing) to use D instead of C#, except for tiny in-house projects. why > database, gui, xml, just to name the top 3 issues. So .. What about an "where C# shines and D sucks" article. Let us start with LINQ in D, or do you prefer to talk about phobos collections ? Bjoern ps don;t get me wrong. I like D.

Simple, they all are library issues. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 29 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 27/11/2010 19:49, BLS wrote:
 On 27/11/2010 04:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

Frankly said, I am a bit nagged by your overoptimistic D view. From my point of view it is opportune to encourage people to use D2 for real world applications. We (our company) having a 20K+ customer base are not able (and willing) to use D instead of C#, except for tiny in-house projects. why > database, gui, xml, just to name the top 3 issues. So .. What about an "where C# shines and D sucks" article. Let us start with LINQ in D, or do you prefer to talk about phobos collections ? Bjoern ps don;t get me wrong. I like D.

I don't understand your criticism, no one said "Hey, look at C#'s mistakes: http://oredev.org/2010/sessions/c-s-greatest-mistakes , therefore C# is crap, and D is better.". There might have been other situations where Andrei has been... "overoptimistic" about D (duck typing comes to mind), but this is not one of them. Instead, it's perfectly valid and useful for D to look at retrospectives about language design (as well as other kinds of commentary and analysis) from people with significant experience in this area. It's good to look for such insights, particularly because D is still in development as a language, so we can better understand what we are doing right, and what we are doing wrong. In other words, it's not a pissing contest between D and C#. (or any non-emergent language for that matter) -- Bruno Medeiros - Software Engineer
Dec 07 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 27 November 2010 14:59:09 BLS wrote:
 On 27/11/2010 16:59, Torarin wrote:
 2010/11/27 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:
 We use template constraints for that kind of stuff.
 
 Andrei

Yes, and that's great, but is there a way to check whether a template argument matches a defined interface?

I could not resist.. We should have Implements! Luca has done some work on it.. but it does not compile anymore. However I think the intension is clear. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&a rticle_id=101673

If you're checking whether it implements an interface, then : should work just like it does with classes. If you're checking whether it has the same functions that an interface requires, then you're not really using interfaces correctly. structs don't implement interfaces. Classes do that. So, either make it a class, or don't use interfaces. If you want to verify that a struct has particular functions needed for the template function in question, then just check whether calling them compiles ( e.g. __traits(compiles, foo.bar()) ). If you have a set of functions that are expected to be there (for instance, to verify that the given type is a certain type of range), then just create template which checks for each of the functions that are supposed to be there and use the template ( e.g. isForwardRange!T ). Interfaces and structs don't have anything to do with each other. - Jonathan M Davis
Nov 27 2010
prev sibling next sibling parent Torarin <torarind gmail.com> writes:
2010/11/28 Jonathan M Davis <jmdavisProg gmx.com>:
 If you have a set
 of functions that are expected to be there (for instance, to verify that the
 given type is a certain type of range), then just create template which checks
 for each of the functions that are supposed to be there and use the template (
 e.g. isForwardRange!T ). Interfaces and structs don't have anything to do with
 each other.

Yes, that works, and you end up with this: template isSomething(T) { enum bool isSomething = is(typeof( { int ret = T.foo(5); string ret2 = T.bar(); T.write(""); }())); } I don't see what's so wrong with being able to do: interface Something { int foo(int); string bar(); void write(); } if (Implements!(Something, T)) Thanks for the link, BLS, I'll see if I can make it work.
Nov 27 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 27 November 2010 16:18:00 BLS wrote:
 On 28/11/2010 00:19, Jonathan M Davis wrote:
 On Saturday 27 November 2010 14:59:09 BLS wrote:
 On 27/11/2010 16:59, Torarin wrote:
 2010/11/27 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:
 We use template constraints for that kind of stuff.
 
 Andrei

Yes, and that's great, but is there a way to check whether a template argument matches a defined interface?

I could not resist.. We should have Implements! Luca has done some work on it.. but it does not compile anymore. However I think the intension is clear. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars. D&a rticle_id=101673

If you're checking whether it implements an interface, then : should work just like it does with classes. If you're checking whether it has the same functions that an interface requires, then you're not really using interfaces correctly. structs don't implement interfaces. Classes do that. So, either make it a class, or don't use interfaces. If you want to verify that a struct has particular functions needed for the template function in question, then just check whether calling them compiles ( e.g. __traits(compiles, foo.bar()) ). If you have a set of functions that are expected to be there (for instance, to verify that the given type is a certain type of range), then just create template which checks for each of the functions that are supposed to be there and use the template ( e.g. isForwardRange!T ). Interfaces and structs don't have anything to do with each other. - Jonathan M Davis

Thanks for taking the time to explain. I've copypasted. However, Given that dCollections enable me to change the underlaying algorithm (say I can replace the default RBTree with SkipList) In order to so that I have to fulfil some requirements. And now, I guess that is what I am talking about. I want a guarantee that my skiplist implementation fulfills the cursor (a structure) requirements. So now what is wrong with the contract from dCollections I am asking for. Please note that dCollections implements cursors as well as ranges.

Interfaces are class-based. Only classes can implement them. It makes no sense to use an interface with structs, because you can't do it. If you're using interfaces with a template, then you simply verify that the type implements the interface in question. You should be able to use : exactly in the same manner that you'd use it to check that a class is a particular type or is derived from a that type. On the other hand, if you're using structs, then the only way that you're going to be able to interchange them based on an API is with templates. A struct cannot implement an interface. So, it makes no sense to talk about a struct implementing one. If you want to ensure that a type that is used to instantiate a template has a certain API, then you verify that in the template constraint, and the way to do that in a manner which is reusable is to use a template which verifies that the type has every function that it's supposed to have. You then use that template in the template constraint. The range templates such as IsForwardRange!() and isInputRang!e() are prime examples of that. You could theoretically create a template which verified that a struct had the same functions that an interface required for a class to implement it, but since a struct can't implement it, it's just confusing and unnecessary to add a useless interface into the mix. The struct can't implement it. And if you you're using a class instead of struct, then the template should verify that the type implements the interface. And if it's templated simply on the type, then you probably don't even need a template - just use the interface itself directly. I don't know exactly what DCollections does. But it's using the language to do whatever it's doing. So, if it's an interface that you need, you have to be using classes, and you can have template constraints verify that the type implements the template. structs never will, so they'll fail the constraint. If, on the other hand, you need to match a particular API - no interfaces involved - then it's going to be a template, and then any template constraints need to verify that whatever functions the template requires are present on the type. No interfaces are involved. Really, if you're trying to have a struct implement an interface (as opposed to an API), then you're misunderstanding how interfaces work. - Jonathan M Davis
Nov 27 2010
prev sibling next sibling parent Torarin <torarind gmail.com> writes:
2010/11/28 Jonathan M Davis <jmdavisProg gmx.com>:
 You could theoretically create a template which verified that a struct had the
 same functions that an interface required for a class to implement it, but
since
 a struct can't implement it, it's just confusing and unnecessary to add a
 useless interface into the mix. The struct can't implement it.

I think it's a matter of taste whether it's confusing or not. I'd say it looks better than the is(typeof({}())) combo, and in some ways it's less confusing. Implement! may be a bad name, because structs will of course not implement the interface in the traditional sense. The interface is just the "concept". Torarin
Nov 27 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 28 November 2010 00:17:30 J=E9r=F4me M. Berger wrote:
 Jonathan M Davis wrote:
 On Saturday 27 November 2010 14:59:09 BLS wrote:
 On 27/11/2010 16:59, Torarin wrote:
 2010/11/27 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:
 We use template constraints for that kind of stuff.
=20
 Andrei

Yes, and that's great, but is there a way to check whether a template argument matches a defined interface?

I could not resist.. We should have Implements! =20 Luca has done some work on it.. but it does not compile anymore. Howev=



 I think the intension is clear.
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=3Ddigitalm=



 D&a rticle_id=3D101673

If you're checking whether it implements an interface, then : should wo=


 just like it does with classes. If you're checking whether it has the
 same functions that an interface requires, then you're not really using
 interfaces correctly. structs don't implement interfaces. Classes do
 that. So, either make it a class, or don't use interfaces. If you want
 to verify that a struct has particular functions needed for the template
 function in question, then just check whether calling them compiles (
 e.g. __traits(compiles, foo.bar()) ). If you have a set of functions
 that are expected to be there (for instance, to verify that the given
 type is a certain type of range), then just create template which checks
 for each of the functions that are supposed to be there and use the
 template ( e.g. isForwardRange!T ). Interfaces and structs don't have
 anything to do with each other.

Note that __traits(compiles, foo.bar()) does not check the return type. If you want to check the return and parameter types, you wind up with a very complex and ugly expression. This is very error prone. Look at the two examples below: =20 Using __traits(compiles...): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

 template isFooBar(T)
 {
    enum bool isFooBar =3D
       __traits (compiles,
       {
          T t;
          int arg;
          int r =3D t.foo (arg);
       })
       &&
       __traits (compiles,
       {
          T t;
          float arg;
          bool r =3D t.bar (arg);
       });
 }
=20
 template Test(T) if (isFooBar!T) ...
 ------------------------------>8=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=20
 Using a fictive "concept" keyword instead of "interface" to avoid
 confusions with true interfaces:
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

 concept FooBar
 {
    int  foo (int);
    bool bar (float);
 }
=20
 template Test(T) if (is!FooBar (T)) ...
 ------------------------------>8=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=20
 	The second one is clearly much easier to write and (especially)
 easier to read, which means:
  - It is faster to write;
  - It will contain a lot fewer errors and bugs (especially once you
 get into more complex concepts);
  - It is immediately self-documenting.
=20
 	Now, it might be possible to do this purely as a library with the
 current language if we are willing to re-use the "interface" keyword
 to define the concepts.

A clearer way to create such template constraints would definitely be nice.= But=20 aside from the fact that I'd absolutely hate to see interfaces be conflated= with=20 template constraints in this manner, you'd need a way to deal with the fact= that=20 the parameters and return types for such functions are frequently dependent= on=20 the type that the template is being instantiated with. A concept as you des= cribe=20 it would have to somehow take templated types into account in a way that=20 interfaces can't. For instance, you could never define an interface which d= efined=20 a forward range like isForwardRange!() does because the interface wouldn't = be=20 properly templatized. What would probably be better would be a template which somehow took a func= tion=20 declaration (including properly using whatever template types that it's sup= posed=20 to) and converted that into a proper template constraint. Something like hasFunction!(T, property ElementType!T front() const) which converted it to a set of constraints using the appropriate templates = from=20 std.traits such as functionAttributes!(), ReturnType!(), and ParameterTypeT= uple! (). I'm not sure whether it's possible to do something like that right now = (I=20 don't think so, but maybe), but it's certainly possible to construct the pi= eces=20 that from std.traits that it would translate into. You could then define a= =20 template such as isForwardRange!() which anded all of the hasFunction!() re= sults=20 for each function that the type is supposed to have to be a forward range. =2D Jonathan M Davis
Nov 28 2010
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 27/11/2010 03:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

Looking at the bit about enums.... Java enums and C, D, etc. enums have their pros and cons. I suppose the main advantages of C enums are: - lightweight - can also be used as bit sets You could argue that bit sets ought to be a separate type. But this precludes uses that combine "proper" enum use with a bit flag or two. Take, from one of my programs, enum Piece : byte { EMPTY, PAWN, BISHOP, KNIGHT, ROOK_CANNOT_CASTLE, ROOK_CAN_CASTLE, QUEEN, KING, BLACK = 8, LAST = Piece.BLACK | KING } The first 8 values are mutually exclusive, BLACK is a bit flag, and LAST is just a marker value. But the compiler doesn't stop you doing silly stuff like Piece.PAWN | Piece.BISHOP. Maybe someone can come up with a better way of doing this.... Java enums preclude having an array indexed by them. I suppose the ability to store data in the enum objects was meant to make up for this. But I recall that somebody in one company I briefly worked for didn't really like Java enums because of this complexity.... Stewart.
Nov 28 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 28 November 2010 18:09:43 Stewart Gordon wrote:
 On 27/11/2010 03:27, Andrei Alexandrescu wrote:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes
 
 Andrei

Looking at the bit about enums.... Java enums and C, D, etc. enums have their pros and cons. I suppose the main advantages of C enums are: - lightweight - can also be used as bit sets You could argue that bit sets ought to be a separate type. But this precludes uses that combine "proper" enum use with a bit flag or two. Take, from one of my programs, enum Piece : byte { EMPTY, PAWN, BISHOP, KNIGHT, ROOK_CANNOT_CASTLE, ROOK_CAN_CASTLE, QUEEN, KING, BLACK = 8, LAST = Piece.BLACK | KING } The first 8 values are mutually exclusive, BLACK is a bit flag, and LAST is just a marker value. But the compiler doesn't stop you doing silly stuff like Piece.PAWN | Piece.BISHOP. Maybe someone can come up with a better way of doing this.... Java enums preclude having an array indexed by them. I suppose the ability to store data in the enum objects was meant to make up for this. But I recall that somebody in one company I briefly worked for didn't really like Java enums because of this complexity....

D has the best of both worlds (or at least will, once bug http://d.puremagic.com/issues/show_bug.cgi?id=4423 has been fixed). You can have enums of primitive types such as int, or you can use structs for more complex types like you'd get in Java. So, you can make your enum whatever type is most appropriate for what you're doing with it. - Jonathan M Davis
Nov 28 2010
prev sibling next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 27.11.2010 04:27, schrieb Andrei Alexandrescu:
 http://oredev.org/2010/sessions/c-s-greatest-mistakes

 Andrei

my 1+ rated mistake getting generics into the language BUT no alias or typedef likes
Nov 29 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, November 28, 2010 04:43:47 J=E9r=F4me M. Berger wrote:
 Jonathan M Davis wrote:
 A clearer way to create such template constraints would definitely be
 nice. But aside from the fact that I'd absolutely hate to see interfaces
 be conflated with template constraints in this manner, you'd need a way
 to deal with the fact that the parameters and return types for such
 functions are frequently dependent on the type that the template is
 being instantiated with. A concept as you describe it would have to
 somehow take templated types into account in a way that interfaces
 can't. For instance, you could never define an interface which defined a
 forward range like isForwardRange!() does because the interface wouldn't
 be properly templatized.

Why not? =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

 concept FooBar(U)
 {
    int  foo (int);
    bool bar (U);
 }
=20
 template Test(T, U) if (is!(FooBar!U, T)) ...
 ------------------------------>8=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=20
 	This already works with class and interface templates...

That may work. I was thinking of a verifying against a concrete interface -= =20 which _wouldn't_ work with templates. I probably didn't think of this becau= se=20 mixing templates and interfaces or classes is generally a bad idea in D, be= cause=20 template functions can't be virtual. =2D Jonathan M Davis
Nov 29 2010