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



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?



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 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
next sibling 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 reply 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
next sibling parent reply 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
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 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 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.
 




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


The more I see these explanations the more I think interface is the wrong 
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
next sibling parent reply 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
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).


Exactly

 
 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.


This is why interfaces fall down when being called "interfaces". They force 
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


That was basically what I was getting at. For me an interface is a 
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 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 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.




 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


 The more I see these explanations the more I think interface is the wrong
 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.




 




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


 The more I see these explanations the more I think interface is the wrong
 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


Actually I am not disagreeing with you. I wasn't talking about a feature 
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:
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. Howev=




er

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




ars.D&a

 rticle_id=3D101673


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


rk just=20

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


unctions=20

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


rectly.=20

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


 a class,=20

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


ular=20

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


 whether=20

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


ve a set=20

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


t the=20

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


 checks=20

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


plate (=20

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


do with=20

 each other.
=20


	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:

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


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


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






er

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






ars.

 D&a rticle_id=3D101673


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




rk

 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.


=20
 	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=


=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);
       });
 }
=20
 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

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


=3D=3D=3D=3D=3D=3D8<------------------------------

 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=


=3D=3D=3D=3D=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
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Jonathan M Davis wrote:

 A clearer way to create such template constraints would definitely be n=


ice. But=20

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


ated 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 depen=


dent on=20

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


 describe=20

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


t=20

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


ch defined=20

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


n't be=20

 properly templatized.
=20


	Why not?

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


=20
 	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=


=3D=3D=3D=3D=3D=3D8<------------------------------

 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=


=3D=3D=3D=3D=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
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
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=




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


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


ce -=20

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


ecause=20

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


, because=20

 template functions can't be virtual.
=20


	That is why I used the word "concept" instead of "interface". What
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 parent reply 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
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 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 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 parent reply Russel Winder <russel russel.org.uk> writes:
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 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:

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 bearophile <bearophileHUGS lycos.com> writes:
Walter:


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


Thank you for the link. In some situations a video/lesson is useful, but in
this case a written text is more efficient.

Regarding the contents, I don't need enums as classes, but I think it's better
for D enums to become a little more strict (as C++0x enums is a good start).

Bye,
bearophile
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+

for tiny in-house projects.  why >  database, gui, xml, just to name the 
top 3 issues.


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+

 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?



 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+

 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)


 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+

 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)


 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 reply 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+

 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)


 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
parent Russel Winder <russel russel.org.uk> writes:
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=


ht?

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

 for tiny in-house projects. why > database, gui, xml, just to name the
 top 3 issues.


 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+

 for tiny in-house projects. why > database, gui, xml, just to name the
 top 3 issues.


 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


Andrei, it is just ... D is not perfect yet.
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 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+

 for tiny in-house projects. why > database, gui, xml, just to name the
 top 3 issues.


 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


 Andrei, it is just ... D is not perfect yet.
 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 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+

 for tiny in-house projects.  why >  database, gui, xml, just to name the 
 top 3 issues.
 

 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


 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+

 for tiny in-house projects.  why >  database, gui, xml, just to name the 
 top 3 issues.


 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+

 for tiny in-house projects.  why>   database, gui, xml, just to name the
 top 3 issues.


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


=3D 1");

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


=20

 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
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 reply 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 ?




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
parent Russel Winder <russel russel.org.uk> writes:
On Sun, 2010-11-28 at 15:57 -0500, Roman Ivanov wrote:
[ . . . ]



 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.


=20
 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


--=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+

 for tiny in-house projects.  why >  database, gui, xml, just to name the  
 top 3 issues.


 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+

 for tiny in-house projects. why > database, gui, xml, just to name the
 top 3 issues.


 with LINQ in D, or do you prefer to talk about phobos collections ?

 Bjoern
 ps don;t get me wrong. I like D.



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


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.

non-emergent language for that matter)

-- 
Bruno Medeiros - Software Engineer
Dec 07 2010
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:


 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.


I was rather interested whether it manages into D2 de jure. Implementation can
be done any time later.
Nov 27 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 bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


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


On enums I hope to see this this tidying enhancement request fulfilled, vote!
:-)
http://d.puremagic.com/issues/show_bug.cgi?id=3999

Bye,
bearophile
Nov 29 2010