 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://weblogs.asp.net/scottgu/archive/2007/03/13/new-orcas-language-feature-extension-methods.aspx
You know, I've wanted something like this since the mid 80's. :-)
Much nicer (and more OO) than "friend" functions, IMO.
It looks like both WinForms and console .NET executables run under Linux
with mono, too, without recompiling or anything. At least for sufficiently
simple stuff. (Ugly buttons etc on Linux, but that's probably a question of
picking good styling.)
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New escreveu:
>
http://weblogs.asp.net/scottgu/archive/2007/03/13/new-orcas-language-feature-extension-methods.aspx
>
>
> You know, I've wanted something like this since the mid 80's. :-)
> Much nicer (and more OO) than "friend" functions, IMO.
Orcs? no, thanks!
Anyway, good to see C# does not merely milks away Delphi, Java and
Python, but now also Ruby.
http://www.25hoursaday.com/weblog/2008/01/23/C30VsRubyThoughtsOnExtensionMethodsAndOpenClasses.aspx
Yes, it's very useful and dangerous too. Side-effect-full,
dynamically-typed imperative programming to the max! Andrew would
collapse just by looking at it... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I haven't read the whole article yet, only up to the first example, but
am wondering why not just use a new class that inherits the string class
and add an email check function there? I'll finish the article later...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
>
http://weblogs.asp.net/scottgu/archive/2007/03/13/new-orcas-language-feature-extension-methods.aspx
>
>
> You know, I've wanted something like this since the mid 80's. :-)
> Much nicer (and more OO) than "friend" functions, IMO.
>
> It looks like both WinForms and console .NET executables run under Linux
> with mono, too, without recompiling or anything. At least for
> sufficiently simple stuff. (Ugly buttons etc on Linux, but that's
> probably a question of picking good styling.)
>
Been using C# 3.0 for a while now. Not necessarily "new". That was so
last year ;)
Anyway ... It is a neat feature, and with linq libraries brought in
using 'using', it adds a ton of extensions to just about anything that
implements IEnumberable, which is part of what makes linq work.
Cool feature, but with great power comes great responsibility...
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kyle wrote:
> I haven't read the whole article yet, only up to the first example, but
> am wondering why not just use a new class that inherits the string class
> and add an email check function there? I'll finish the article later...
Say, for instance you don't own the class you're extending and the class
is sealed (you can no longer inherit) the function you want to add
doesn't need the internals of the class, but would be convenient if it
were part of the class. Or say you don't want to have to declare all
strings that use your new method as
KylesStuff.Coolthings.KylesCoolString you'd rather keep your existing
codebase, and have this extension available to the new code that will be
using it. Obviously a function that takes a KylesCoolString isn't going
to accept a string, though you could create an implicit conversion, just
to make things easier.
or, you simmply add an extension function to string, and not deal with
the issues surrounding inheritance. The extension function simply acts
as if it was there the whole time. A way of extending a class without
messing with the class or creating a new class, if you will.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Orcs? no, thanks!
I think "Orca" is the code name for C# 2008 back in 2007. :-)
> Anyway, good to see C# does not merely milks away Delphi, Java and
> Python, but now also Ruby.
Yep! Except doing it with a strongly-typed component-friendly approach. :-)
You always could do it in Smalltalk, just like you do in Ruby. One advantage
C# has is that you're not *actually* changing the string class; it's just
syntactic sugar. It's more like a C++ friend, except with method/object syntax.
And if one library writes an "In()" function for collections, and another
library writes an "In()" function for collections, there's no collision.
The problem with doing it in Smalltalk (or Ruby for that matter, I suspect)
is that you wind up horking up any libraries that might have conflicts, and
you wind up with workspaces that that can't share code. (Indeed, the whole
"workspace" concept in Smalltalk seems like a bad idea in hindsight, or at
least extremely hard to manage in spite of all the help the environment
gives you. :-)
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kyle wrote:
> I haven't read the whole article yet, only up to the first example, but
> am wondering why not just use a new class that inherits the string class
> and add an email check function there?
Because every function that currently returns a string doesn't have your
extra code added. Every read from a file, every concatenation of two
strings, every string literal, every element on a web page, every attribute
from an XML file, every packet from a socket: all need to get converted to
your type before you can use them.
The "email check" function might be a poor example.
Think of a "point" object, where you want to be able to calculate the
distance, for example. Now you have rectangles holding points, windows
holding rectangles, etc., and you have extra syntax to turn the points in
the rectangles in the windows into MyPoint objects, just so you can apply
the method. Or using a separate function unrelated to points and which
doesn't show up in intelisense.
Plus, of course, that doesn't work if for some reason you can't inherit from
the object, like it being an integer or something.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> Been using C# 3.0 for a while now. Not necessarily "new". That was so
> last year ;)
Well, I haven't been using C# lately, so....
Too many people want Linux crap, and think they really *need* C++ to go as
fast as possible, in spite interfacing to a MySQL server or some silliness.
> Anyway ... It is a neat feature, and with linq libraries brought in
> using 'using', it adds a ton of extensions to just about anything that
> implements IEnumberable, which is part of what makes linq work.
Cool. Any recommendations on good books for the stuff in C# 3 that's not in
C# 2? Lots of books, but hard to evaluate. :-) Any you found particularly
good or bad?
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Mike Raiford wrote:
>> Been using C# 3.0 for a while now. Not necessarily "new". That was so
>> last year ;)
>
> Well, I haven't been using C# lately, so....
>
> Too many people want Linux crap, and think they really *need* C++ to go
> as fast as possible, in spite interfacing to a MySQL server or some
> silliness.
>
I had to tease, though ... :)
>
> Cool. Any recommendations on good books for the stuff in C# 3 that's not
> in C# 2? Lots of books, but hard to evaluate. :-) Any you found
> particularly good or bad?
>
I haven't actually done a whole lot of reading, except for the
documentation and online resources and working with it. There was a book
being passed around here (Pro LINQ) that some people said was rather
good, but I hadn't had a chance to look at it yet.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
>
http://weblogs.asp.net/scottgu/archive/2007/03/13/new-orcas-language-feature-extension-methods.aspx
>
Funny to see a post titled "*new* C# stuff" with a link to a March 2007 blog
post :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 21 Jan 2009 21:17:56 +0100, Darren New <dne### [at] san rrcom> wrote:
>
> You always could do it in Smalltalk, just like you do in Ruby. One
> advantage C# has is that you're not *actually* changing the string
> class; it's just syntactic sugar. It's more like a C++ friend, except
> with method/object syntax.
It is nothing like 'friend' in C++. As I understand it, extensions only
have access to the public interface of the extended class. Semantically,
they seem much more like ordinary free functions in C++.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fredrik Eriksson wrote:
> On Wed, 21 Jan 2009 21:17:56 +0100, Darren New <dne### [at] sanrrcom> wrote:
>>
>> You always could do it in Smalltalk, just like you do in Ruby. One
>> advantage C# has is that you're not *actually* changing the string
>> class; it's just syntactic sugar. It's more like a C++ friend, except
>> with method/object syntax.
>
> It is nothing like 'friend' in C++.
Well, yes, there are a lot of differences. I suppose in thinking more it's
not really like "friend" at all, no. :-)
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Funny to see a post titled "*new* C# stuff" with a link to a March 2007 blog
> post :)
Well, it's the newest version of C#. :-)
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> On Wed, 21 Jan 2009 21:17:56 +0100, Darren New <dne### [at] sanrrcom> wrote:
> >
> > You always could do it in Smalltalk, just like you do in Ruby. One
> > advantage C# has is that you're not *actually* changing the string
> > class; it's just syntactic sugar. It's more like a C++ friend, except
> > with method/object syntax.
> It is nothing like 'friend' in C++. As I understand it, extensions only
> have access to the public interface of the extended class. Semantically,
> they seem much more like ordinary free functions in C++.
Unless I'm missing something, I really fail to see how this is a
useful feature.
Basically, it seems, that instead of having to write, for example,
"someFunction(anObject)" you can write "anObject.someFunction()".
In other words, you simply can write the same thing with a slightly
different syntax, but otherwise there's no difference. I really fail
to see the usefulness of this.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
>> On Wed, 21 Jan 2009 21:17:56 +0100, Darren New <dne### [at] sanrrcom> wrote:
>>> You always could do it in Smalltalk, just like you do in Ruby. One
>>> advantage C# has is that you're not *actually* changing the string
>>> class; it's just syntactic sugar. It's more like a C++ friend, except
>>> with method/object syntax.
>
>> It is nothing like 'friend' in C++. As I understand it, extensions only
>> have access to the public interface of the extended class. Semantically,
>> they seem much more like ordinary free functions in C++.
>
> Unless I'm missing something, I really fail to see how this is a
> useful feature.
>
> Basically, it seems, that instead of having to write, for example,
> "someFunction(anObject)" you can write "anObject.someFunction()".
>
> In other words, you simply can write the same thing with a slightly
> different syntax, but otherwise there's no difference. I really fail
> to see the usefulness of this.
>
Its syntatic sugar. A convenience.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Basically, it seems, that instead of having to write, for example,
> "someFunction(anObject)" you can write "anObject.someFunction()".
Syntax sugar. And let lets you do things like
"Hello".toUpper().myConversion().trim("o")
so you can chain them together.
The same benefit you get in C++ from being able to make classes with no
virtual members. You often talk about how you can have an array of points
in C++ without any extra overhead and still treat them like objects, yes?
Same sort of thing here.
Note too that it might interact with overloading and implicit casts.
short s = ...;
s.myThing(); // I know what this calls.
yourThing(s); // Does this cast "s" to an integer first?
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Basically, it seems, that instead of having to write, for example,
> > "someFunction(anObject)" you can write "anObject.someFunction()".
> Syntax sugar. And let lets you do things like
> "Hello".toUpper().myConversion().trim("o")
> so you can chain them together.
> The same benefit you get in C++ from being able to make classes with no
> virtual members. You often talk about how you can have an array of points
> in C++ without any extra overhead and still treat them like objects, yes?
> Same sort of thing here.
I'm not sure it's the same thing.
The idea with having objects rather than raw data is that objects can
be made abstract, ie. have an abstract public interface which hides the
implementation).
I don't see how "anObject.someFunction()" hides the implementation
better than "someFunction(anObject)", especially given that the former
does not add any access rights for the function in question (like
declaring a function as friend would).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> The idea with having objects rather than raw data is that objects can
> be made abstract, ie. have an abstract public interface which hides the
> implementation).
So why is it better to have member functions at all, vs just passing the
object to a function? What's the benefit of being able to say
p = pixels[23].lightened();
vs
p = lightened(pixels[23]); // Like you would in Java
> I don't see how "anObject.someFunction()" hides the implementation
> better than "someFunction(anObject)",
Because it looks like it's part of the class. You don't have to remember
which members are built in and which ones were added by a library you're using.
For example, there's LINQ (which is sort of
relational-queries-on-all-data-types), which adds all sorts of query
semantics to built-in enumerations and such. So you can do something like
var people = new array[] {
new Person("Fred", ...),
new Person("Steve", ...),
....
};
var query = people.Where(p=>p.Name.startsWith("S"))
.Select(p=>p.Name.toUpper());
That gives you back an enumeration over the uppercased names of the people
in the array whose name starts with "S". The "Where" and "Select" names were
added by LINQ.
But yeah, it's syntactic sugar. It lets you add methods to classes (and
their subclasses) that are already in existence without modifying the
already-compiled classes. It's syntactic sugar, in the same way that any
distinguished-caller syntax in a method-oriented OO language is syntactic sugar.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Fredrik Eriksson wrote:
>> On Wed, 21 Jan 2009 21:17:56 +0100, Darren New <dne### [at] sanrrcom> wrote:
>>>
>>> You always could do it in Smalltalk, just like you do in Ruby. One
>>> advantage C# has is that you're not *actually* changing the string
>>> class; it's just syntactic sugar. It's more like a C++ friend, except
>>> with method/object syntax.
>>
>> It is nothing like 'friend' in C++.
>
> Well, yes, there are a lot of differences. I suppose in thinking more
> it's not really like "friend" at all, no. :-)
Thinking more, it's exactly the *opposite* of friend.
A friend function lets you take something with function-call syntax and give
it access to the private bits of a class as if it were a member.
This thing in C# lets you take something with function-call semantics and
make it look like a member function without giving it access to the private
parts of the class.
But it *is* something that I've missed in lots of OO languages - the ability
to "fix" the built-in classes or classes in libraries without having to
subclass them and deal with getting the right classes instantiated.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> In other words, you simply can write the same thing with a slightly
> different syntax, but otherwise there's no difference. I really fail
> to see the usefulness of this.
It *is* syntax sugar.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > The idea with having objects rather than raw data is that objects can
> > be made abstract, ie. have an abstract public interface which hides the
> > implementation).
> So why is it better to have member functions at all, vs just passing the
> object to a function? What's the benefit of being able to say
> p = pixels[23].lightened();
> vs
> p = lightened(pixels[23]); // Like you would in Java
The benefit is that, at least in theory, the member function can be
dynamically bound, while the regular function can't.
With static member functions I suppose it doesn't make too much of a
difference (except that they are less writing because you don't have to
befriend all the functions explicitly).
Although in some situations it could make a difference also with static
member functions, regarding to access rights. For example, a member
function of a derived class can access the functions in the protected
part of the base class, but an regular function can't. (Making the regular
function a friend of the base class would open even the private part of
it, which might not be what you want.)
> > I don't see how "anObject.someFunction()" hides the implementation
> > better than "someFunction(anObject)",
> Because it looks like it's part of the class. You don't have to remember
> which members are built in and which ones were added by a library you're using.
One could maybe argue that that's a *bad* thing. If it looks like part
of the class but isn't, that might cause problems when you reuse the class
somewhere else, where you might not have the extension in question.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> The benefit is that, at least in theory, the member function can be
> dynamically bound, while the regular function can't.
But not on an object that only occupies four bytes, which is your usual
example. :-)
> Although in some situations it could make a difference also with static
> member functions, regarding to access rights. For example, a member
> function of a derived class can access the functions in the protected
> part of the base class, but an regular function can't. (Making the regular
> function a friend of the base class would open even the private part of
> it, which might not be what you want.)
C# also has an assembly-level rights declaration. So instead of friends, you
declare the things you want befriended "internal". So for example, the link
pointers in a linked list cell can be tagged "internal", which basically
means any other classes in the same DLL can access them[1].
>> Because it looks like it's part of the class. You don't have to remember
>> which members are built in and which ones were added by a library you're using.
>
> One could maybe argue that that's a *bad* thing. If it looks like part
> of the class but isn't, that might cause problems when you reuse the class
> somewhere else, where you might not have the extension in question.
It isn't defined as part of the class. That's kind of the point. It's
declared[2] only where you import it. Hence, you can make such an extention
for your code, and I can make one for my code, and it doesn't conflict
unless I want to use both, at which point I fall back to the
fully-namespace-qualified form of the call. Unless I import the module
defining the function, the function isn't visible as a pseudo-member.
Incidentally, you can also declare something as a "partial member function"
in a class, which gives it a declaration but not a definition. If you never
define it, calls to it act like they are just empty functions (i.e., they
have no effect). If you do define it, then the function gets called. (I
haven't really followed this up much, but I'm guessing it has to be a void
function, and I'm not sure how this is helpful in the given environment, but
it's not the sort of thing you put in without a use case in mind. :-)
This is distinct from a "partial class", where the code (and declarations)
for one class are split across multiple source files.
[1] Lies-to-children. It's a bit more complicated than that, but that's the
basics of it.
[2] ...to use the terminology of C here distinguishing declare/define.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> The idea with having objects rather than raw data is that objects can
>>> be made abstract, ie. have an abstract public interface which hides the
>>> implementation).
>
>> So why is it better to have member functions at all, vs just passing the
>> object to a function? What's the benefit of being able to say
>> p = pixels[23].lightened();
>> vs
>> p = lightened(pixels[23]); // Like you would in Java
>
> The benefit is that, at least in theory, the member function can be
> dynamically bound, while the regular function can't.
BTW, it *can* be dynamically bound in languages where this is supported. Ada
leaps to mind. There's no distinguished-caller syntax in Ada - all the OO
features are done by what *looks* like overloading but actually turns out to
be dynamic binding if you've said to do so.
But yeah, it's syntax sugar, like overloading operators is.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > The benefit is that, at least in theory, the member function can be
> > dynamically bound, while the regular function can't.
> But not on an object that only occupies four bytes, which is your usual
> example. :-)
Ok, if it takes 8 bytes, then it could have virtual functions. ;)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> -----Original Message-----
> From: Warp [mailto:war### [at] tagpovrayorg]
> In other words, you simply can write the same thing with a slightly
> different syntax, but otherwise there's no difference. I really fail
> to see the usefulness of this.
You're terribly correct, there is no use to this at all. After all, the
following are all identical:
VectorAdd(v1, v2, &v3);
v3 = VectorAdd(v1,v2);
v3 = v1+v2;
Since there's no difference between them, the second two should just be
taken out completely, don't you think?
...Ben Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> But yeah, it's syntax sugar, like overloading operators is.
And if anyone cares, here's a fairly complex query written in LINQ, in C#
with extension methods, and in C# without extension methods.
http://www.interact-sw.co.uk/iangblog/2005/09/30/expressiontrees
about 3/4ths the way down, after the text "A little further into the demo"
Pretty cool. Especially since there's an Expression.Compile() instance
method that will generate actual CIL code for a parse tree you created at
runtime. (A la http://www.jot.fm/issues/issue_2008_03/column4.pdf ). But
AFAIK, once you've created CIL code, you can't unload it, at least not
without dumping the whole assembly context, so it winds up being a sort of
resource leak if you do this dynamically too much. I've seen libraries to
manage this, tho, starting with multiple assemblies and dumping them when
they get full, restarting with new ones. Seems kind of kludgey.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> > -----Original Message-----
> > From: Warp [mailto:war### [at] tagpovrayorg]
> > In other words, you simply can write the same thing with a slightly
> > different syntax, but otherwise there's no difference. I really fail
> > to see the usefulness of this.
> You're terribly correct, there is no use to this at all. After all, the
> following are all identical:
> VectorAdd(v1, v2, &v3);
> v3 = VectorAdd(v1,v2);
> v3 = v1+v2;
> Since there's no difference between them, the second two should just be
> taken out completely, don't you think?
Ah, so this extension can be used for operator overloading in C#?
Nobody told me that before.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Ah, so this extension can be used for operator overloading in C#?
> Nobody told me that before.
Operator overloading has existed since C# 1.0
I think the poster was trying to demonstrate a syntatic sugar feature
you may be familiar with and might like.
Rather than using, for example:
GraphicsExtensions.DrawButton(g, rcArea, caption);
You could define it so you simply type
g.DrawButton(rcArea, caption);
It just simplifies things a bit.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Warp wrote:
> > Ah, so this extension can be used for operator overloading in C#?
> > Nobody told me that before.
> Operator overloading has existed since C# 1.0
I was being sarcastic.
> I think the poster was trying to demonstrate a syntatic sugar feature
> you may be familiar with and might like.
And the demonstration was invalid.
We are talking about "object.function()" vs. "function(object)", not
about "a+b+c" vs. "add(a, add(b, c))".
> Rather than using, for example:
> GraphicsExtensions.DrawButton(g, rcArea, caption);
> You could define it so you simply type
> g.DrawButton(rcArea, caption);
I see no relevant difference to making a function so that you can write
"DrawButton(g, rcArea, caption)".
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> I see no relevant difference to making a function so that you can write
> "DrawButton(g, rcArea, caption)".
>
Except that in C# everything is defined in a class. So, if the function
is part of a library, you'd have to either define static methods or
instance methods. The Graphics class is sealed, so there's no means of
defining a sub class, such as GraphicEx ...so your choices are define a
bunch of static methods, or define a class whose constructor takes a
pointer to a Graphics object, and offers the extended functions.
C# 3.0 offers the extension methods to get around this. It may seem like
a pointless feature to you, but for some it is a minor convenience.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> -----Original Message-----
> From: Warp [mailto:war### [at] tagpovrayorg]
> Ah, so this extension can be used for operator overloading in C#?
> Nobody told me that before.
Actually, it can't, but that's irrelevant.
You said:
"In other words, you simply can write the same thing with a slightly
different syntax, but otherwise there's no difference. I really fail to
see the usefulness of this."
In other words, you see no usefulness in having syntactic sugar. I
think it's useful.
...Ben Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> In other words, you see no usefulness in having syntactic sugar. I
> think it's useful.
Especially when you want to chain methods together to make things work.
Writing
myCollection.Select(...).Group(...).Transform(...).Sort(...).Output()
is a lot more clear than
Sort(Group(myCollection.Select(...)).Transform(...)).Output()
just like writing
cout << 123 << endl << mystuff.xyz() << endl
is more clear than
cout.write(cout.write(123).endl(), mystuff.xyz()).endl()
or something like that.
Plus, it interacts with other syntax of the language that the compiler turns
into syntax like this. When your C++ sorting template has to know whether
the right call is myThing.compare(otherThing) or
MyUtil.compare(myThing,otherThing), it gets messy. That's exactly what this
is for, so it's pretty much just like what operator overloading is for.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> Actually, it can't, but that's irrelevant.
> You said:
> "In other words, you simply can write the same thing with a slightly
> different syntax, but otherwise there's no difference. I really fail to
> see the usefulness of this."
> In other words, you see no usefulness in having syntactic sugar. I
> think it's useful.
No. What I said was that I don't see usefulness IN THIS CASE. The
difference is practically nonexistent. It's only in reordering of
names.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> No. What I said was that I don't see usefulness IN THIS CASE. The
> difference is practically nonexistent. It's only in reordering of
> names.
It lets code generation tools (and LINQ) generate code in one pattern
(distinguished caller syntax) for both methods defined on the class and
methods defined outside the class.
It gives you the same benefit that having the name "operator<" available
does. If you want to do a sort in C of integers, you call
qsort(myArray, myCompare);
int myCompare(int a, int b) {return a < b;}
In C++ you call
qsort(myArray, operator< );
or some such syntax, but without the need to have a specifically named
function just to wrap up the < operator.
Plus, of course, it lets the same member-syntax function mean different
things in different places in your code. Here, xyz.Select(...) means one
function, while there xyz.Select(...) means a different function. This is
important when "here" and "there" are two compiled libraries from two
different sources and you're automatically generating the code.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> In C++ you call
> qsort(myArray, operator< );
> or some such syntax, but without the need to have a specifically named
> function just to wrap up the < operator.
std::sort(myArray) is all you need. Guess *how* the operator< is used by
default?
template <typename T> bool less(const T& x, const T& y) {
return x < y;
}
std::sort uses std::less as the default sorting function.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Darren New wrote:
>> In C++ you call
>> qsort(myArray, operator< );
>> or some such syntax, but without the need to have a specifically named
>> function just to wrap up the < operator.
>
> std::sort(myArray) is all you need. Guess *how* the operator< is used by
> default?
>
> template <typename T> bool less(const T& x, const T& y) {
> return x < y;
> }
>
> std::sort uses std::less as the default sorting function.
>
Yep. And now what do you do if the "less" you want to use is actually a
member function of type T? What if the "less" you want to use is
class MyDate {
bool comesBefore(const MyDate& otherDate);
}
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Yep. And now what do you do if the "less" you want to use is actually a
> member function of type T? What if the "less" you want to use is
> class MyDate {
> bool comesBefore(const MyDate& otherDate);
> }
You create a comparator and give that to std::sort. A comparator can be,
for example, a (regular) function which takes two elements and returns bool.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Yep. And now what do you do if the "less" you want to use is actually a
>> member function of type T? What if the "less" you want to use is
>> class MyDate {
>> bool comesBefore(const MyDate& otherDate);
>> }
>
> You create a comparator and give that to std::sort. A comparator can be,
> for example, a (regular) function which takes two elements and returns bool.
And that's precisely what the C# syntax avoids you having to do, in the
other direction.
It's in there most likely because of LINQ, which is a bit of the language
that turns something that looks a bit like SQL into something that looks
like method calls. If there were two syntaxes for each possible call that
LINQ generated, you'd have a mess. So now
int xyz(this T alpha, U beta)
is a valid overloaded function candidate for
alpha.xyz(beta)
when alpha is a T and beta is a U.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> Yep. And now what do you do if the "less" you want to use is actually a
> >> member function of type T? What if the "less" you want to use is
> >> class MyDate {
> >> bool comesBefore(const MyDate& otherDate);
> >> }
> >
> > You create a comparator and give that to std::sort. A comparator can be,
> > for example, a (regular) function which takes two elements and returns bool.
> And that's precisely what the C# syntax avoids you having to do, in the
> other direction.
So instead of writing a function which takes two objects and returns
a bool, you write a "member function" which which called with one object,
takes another as parameter, and returns bool?
I'm still not seeing the huge difference.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> So instead of writing a function which takes two objects and returns
> a bool, you write a "member function" which which called with one object,
> takes another as parameter, and returns bool?
Yes.
> I'm still not seeing the huge difference.
That it's the same syntax regardless of whether it's a member function or a
function the user added later, which makes it easier for code generators.
Just like having operator= on classes makes it easier to write templates
than if you had to know whether to use (i = j) for integers and i.equals(j)
for complex numbers.
That you don't have to remember which functions were added after the fact
and which functions were part of the original class.
That you can chain a sequence of calls together that are both members and
non-members without having to skip back and forth around the line to figure
out what order they get evaluated in.
Writing
myCollection.Select(...).Group(...).Transform(...).Sort(...).Output()
is a lot more clear than
Sort(Group(myCollection.Select(...)).Transform(...)).Output()
just like writing
a = b + c * d - e
is more clear than
a = subtract(add(b, multiply(c, d)), e)
It isn't a "huge" difference, any more than operator overloading makes a
"huge" difference to the language. But that's why it's there. If you don't
see why it's a benefit, you either should just let it go, or read the C#
spec that relates it to the other features of C#.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> -----Original Message-----
> From: Warp [mailto:war### [at] tagpovrayorg]
> I'm still not seeing the huge difference.
Maybe that's because you're looking for a huge difference, and there
isn't one.
It's a small difference that can make things a little easier on you.
Are you going to seriously complain that that's a bad thing?
...Ben Chambers
www.pacificwebguy.com
What's the difference between a drug dealer and a whore?
A whore can wash her crack and sell it again.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> It's a small difference that can make things a little easier on you.
> Are you going to seriously complain that that's a bad thing?
The original post made it sound like a really big deal. That's what
I was objecting against. (Or, more precisely, I couldn't understand what
exactly was such a big deal about it that deserved a whole new thread
about the subject.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> The original post made it sound like a really big deal.
Really?
"You know, I've wanted something like this since the mid 80's. :-)"
> (Or, more precisely, I couldn't understand what
> exactly was such a big deal about it that deserved a whole new thread
> about the subject.)
It wasn't. Everybody just jumped on that sentence and ignored the second
half of the post. I was hoping someone with broader experience using Mono
might have mentioned some of the parts that *don't* work ok under Linux, for
example.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
