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