"Glen Perkins" <Glen_member@pathlink.com> wrote in message news:dmbi58$2blo$1@digitaldaemon.com...
> . Query expressions, which provide a language integrated syntax for
> queries that
> is similar to relational and hierarchical query languages such as SQL and
> XQuery.

That's a pretty neat idea!

L.

> . Extension methods, which make it possible to extend existing types and constructed types with additional methods.

Which is stolen directly from Delphi.Net, which has the ability to "inject" new methods into .Net classes - and has since the field test, pre version 1.0 of Delphi.Net. Admittedly, Borland did it through compiler "hacks" (guessing) but still - it may be new to Microshaft "D-Flat", but it's not "new" to .Net at all.

In article <dmeieu$1q0v$1@digitaldaemon.com>, Munchgreeble says...
>
>clayasaurus wrote:
>> I just want to see D 1.0 :)
>> 
>I agree! There will always be more new ideas to take on board, but I think finishing implementing the great list of features that D already has ironing out the issues with those has got to be more important...

I definitely agree. I think the LINQ feature, though, would be particularly useful. Having a standard, built-in SQLish language syntax for querying data, whether it be located in an array, a container, a disk file, a remote Web service, a relational database, etc., would be a great feature in D. Being the only high-performance, natively compiled language with this feature could be a real attention getter for D.

So all I'm hoping is that Walter will just reserve room for it in D's syntax space so that after D 1.0 ships, he won't have to choose between leaving it out or making a Perlish mess of D's syntax.

In article <dmd5hb$jk4$1@digitaldaemon.com>, Ivan Senji says...
>
>John Reimer wrote:
>> Ivan Senji wrote:
>>>
>>> I would like to here the official opinion on this feature because i don't think it is even documented, and that might mean this feature is not intended but only a bug in the current implementation. It would IMO be great if it really was a feature and extended to all types.
>> 
>> 
>> I believe it was an accidental feature that quickly became accepted as useful when it was discovered.  It's been discussed in this group several times before.
>> 
>
>Yes i know, but Walter never participated in any of those discussions.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/18038

FWIW, I think the feature is good, and should be extended to other types. BUT, it is a little "dodgy" the way it is (or rather isn't) defined at the moment. Perhaps, instead of allowing ANY function to be called this way (which could get confusing), we should have some special syntax, eg.

int square1(int x) { return x*x; }
auto int square2(int x) { return x*x; }

int a = 10;
a.square1(); // Doesn't work
b.square2(); // Works.

Ok, 'auto' is probably not a good keyword to use, but you get my drift :)

Nick

Nick wrote:
> In article <dmd5hb$jk4$1@digitaldaemon.com>, Ivan Senji says...
> 
>>John Reimer wrote:
>>
>>>Ivan Senji wrote:
>>
>>Yes i know, but Walter never participated in any of those discussions.
> 
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/18038
> 

Wow, thanks Nick, i don't know how i missed that. Good to know.

> FWIW, I think the feature is good, and should be extended to other types. BUT,
> it is a little "dodgy" the way it is (or rather isn't) defined at the moment.
> Perhaps, instead of allowing ANY function to be called this way (which could get
> confusing), we should have some special syntax, eg.
> 
> int square1(int x) { return x*x; }
> auto int square2(int x) { return x*x; }
> 
> int a = 10;
> a.square1(); // Doesn't work
> b.square2(); // Works.
> 
> Ok, 'auto' is probably not a good keyword to use, but you get my drift :)
> 

I get it. Since this was a C# 3.0 thread i think using that syntax that would be:

int square2(this int x) { return x*x; }

Althoug i wouldn't mind living without that special syntax, just hope that it gets implemented for other types. I don't think it should be that difficult to do it.

Ivan Senji wrote:
> Nick wrote:
> 
>> In article <dmd5hb$jk4$1@digitaldaemon.com>, Ivan Senji says...
>>
>>> John Reimer wrote:
>>>
>>>> Ivan Senji wrote:
>>>
>>>
>>> Yes i know, but Walter never participated in any of those discussions.
>>
>>
>>
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/18038
>>
> 
> Wow, thanks Nick, i don't know how i missed that. Good to know.
> 
>> FWIW, I think the feature is good, and should be extended to other types. BUT,
>> it is a little "dodgy" the way it is (or rather isn't) defined at the moment.
>> Perhaps, instead of allowing ANY function to be called this way (which could get
>> confusing), we should have some special syntax, eg.
>>
>> int square1(int x) { return x*x; }
>> auto int square2(int x) { return x*x; }
>>
>> int a = 10;
>> a.square1(); // Doesn't work
>> b.square2(); // Works.
>>
>> Ok, 'auto' is probably not a good keyword to use, but you get my drift :)
>>
> 
> I get it. Since this was a C# 3.0 thread i think using that syntax that would be:
> 
> int square2(this int x) { return x*x; }

This is a nice syntax. Does C# allow this function to be called as both square(5) and 5.square() or only 5.square()?

This is the perfect way to allow a library define things such as c.conj

/Oskar

Oskar Linde wrote:
> Ivan Senji wrote:
>> int square2(this int x) { return x*x; }
> 
> 
> This is a nice syntax. Does C# allow this function to be called as both square(5) and 5.square() or only 5.square()?
> 

I'm not sure, i didn't find any mention of it in the 3.0 spec.

> This is the perfect way to allow a library define things such as c.conj
> 

I think so too. It would introduce endless possibilities.

Nick wrote:
> In article <dmd5hb$jk4$1@digitaldaemon.com>, Ivan Senji says...
> 
>>John Reimer wrote:
>>
>>>Ivan Senji wrote:
>>>
>>>>I would like to here the official opinion on this feature because i don't think it is even documented, and that might mean this feature is not intended but only a bug in the current implementation. It would IMO be great if it really was a feature and extended to all types.
>>>
>>>
>>>I believe it was an accidental feature that quickly became accepted as useful when it was discovered.  It's been discussed in this group several times before.
>>>
>>
>>Yes i know, but Walter never participated in any of those discussions.
> 
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/18038
> 
> FWIW, I think the feature is good, and should be extended to other types. BUT,
> it is a little "dodgy" the way it is (or rather isn't) defined at the moment.
> Perhaps, instead of allowing ANY function to be called this way (which could get
> confusing), we should have some special syntax, eg.
> 
> int square1(int x) { return x*x; }
> auto int square2(int x) { return x*x; }
> 
> int a = 10;
> a.square1(); // Doesn't work
> b.square2(); // Works.
> 
> Ok, 'auto' is probably not a good keyword to use, but you get my drift :)
> 
> Nick
> 
> 

what about to use "this" as function argument name?

int square(int this) {return this*this;}

And to apply the same rules for other types including arrays.

Glen Perkins wrote:

Replying a little late to this but i have some more comments after playing around with C# 3.0 a little.

> 
> •	Implicitly typed local variables, which permit the type of local variables to
> be inferred from the expressions used to initialize them.
> •	Extension methods, which make it possible to extend existing types and
> constructed types with additional methods.
> •	Lambda expressions, an evolution of anonymous methods that provides improved
> type inference and conversions to both delegate types and expression trees.
> •	Object initializers, which ease construction and initialization of objects.
> •	Anonymous types, which are tuple types automatically inferred and created from
> object initializers.

I dropped query expressions from this list as they are only syntax sugar for invoking query related extension methods.

I would just like to comment a little on how near/far D is to these things. Implicitly typed local variables we have, extensions methods we could have (as we have them for arrays), lambda extensions we don't have but they are only syntax sugar for delegates, so not a real problem.

The bigger problem is not having object initializers and anonymous types. As allways a little example:

C# 3.0 code:

var persons = new []
	{ new {Name = "ivan", Phone = "", Adress = ""},
          new {Name = "ira", Phone = "", Adress = ""},
          new {Name = "bla", Phone = "", Adress = ""} };

//a query to get names of persons that begin with 'i'
var imena = d.Where(o => o.Name[0] == 'i').Select(o => o.Name);

foreach(var name in imena)
{
  Console.WriteLine(name);
}

Now that looks very simple an intuitive, what about doing this in D:

The problem is the actual source is ~40 lines because you have to declare the type that stores persons, and have to declare a type that stores the projection result with their apropriate constructors, members and properties.

The actual query in D (with a generic Select method doesn't look that bad):

JustNames[] names =
  Where!(Person,JustNames)
    (d,delegate bool(Person src){return src.name[0]=='i';});

(It would be a little better with type inference but in this simple case this is not a big problem)

Conslusion: anonymous types coupled with object initializers is what gives new power to C# 3.0 and could be an interesting (maybe D 1.1) addition to D as it has so many other advantages over C# 3.0 (except std library) for example slices, nested functions (that I can't live without) ...