![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> -----Original Message-----
> From: Warp [mailto:war### [at] tag povray org]
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chambers <ben### [at] pacificwebguy com> wrote:
> > -----Original Message-----
> > From: Warp [mailto:war### [at] tag povray org]
> > 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |