 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
>> C# uses delegates, instead.
>
> How do they work for member functions?
>
Transparently.
e.g.
delegate void myDel(int x);
class SomeClass
{
public int myValue;
public void DoInstanceStuff(int x)
{
myValue = x;
}
public static void Main()
{
SomeClass c = new SomeClass();
myDel d = c.DoInstanceStuff
d(6); // this sets c.myValue to 6;
}
}
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp escreveu:
> The fact is: If a programming language supports types, if it also
> supports abstract user-defined types, it becomes an order of magnitude
> more expressive and useful. And abstract user-defined types are objects
> (in the OO sense).
But that's within a function composition environment. I don't like OO's
step-by-step, verbose and multilayered approach of redundancy. I also
don't like all the naming conventions done for the sake of stupid,
easily replaceable drones programming in big enterprises, like as if
they were programming in notepad rather than in contextful high-end
IDEs. Then again, perhaps even Haskell would follow the same fate were
it to be endorsed by the industry...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> What is the difference between a multicast delegate, as shown here, and
> an event?
An event is a delegate with only += and -= exposed outside the class. I.e.,
declaring an event vs a delegate is like declaring a protected member vs a
public member. Same type of object, different visibility for callers.
--
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] san rrcom> wrote:
>> I think better would be the way you wind up having to do it in Java - you
>> have a class that implements a "parse this" method for each possible
>> argument to be parsed, and the parser has a map from "-debug" to an instance
>> of the class that parses the debug parameter. So you have one subclass for
>> each parser function. Ugly, but not as bad as a giant switch statement.
>
> Actually that's the most cumbersome solution
OK. By "better" I meant perhaps "more maintainable" or "more reusable" or
"more OO". The way I suggested lets you easily reuse the parser classes in
other programs, for example. I can write a "-geom" parser and you can write
a "-regex" parser, and Fred can combine them into one program easily.
>> FWIW, a delegate *is* an object that behaves like a function (your "functor
>> object"). You write something like
>
> Does it also work for member functions?
Yes. Anything that'll take a float and return an integer works. So you can
combine a static function that takes a float and returns an integer, plus a
member function that takes an instance (as a distinguised parameter, i.e.,
in "o.xyz()" syntax) and a float and returns an integer, and have them both
in the delegate at the same time.
> Member function pointers are a bit complicated in C++, but they can
> be useful (as in my command line parser example). Obviously to call a
> member function of a class through a pointer you need also the object for
> which the function is called. The syntax for calling such a function is:
>
> object.*functionPointer(parameters);
Yah. A C# delegate wraps up both the instance and the member method in one
syntax. So you'd say
class Thing {
static public int pdq(float y) { ... }
public abc(float z) { return (int) (z*this.stuff); }
int stuff;
Thing() { stuff = 28; }
}
Thing o = new Thing();
delegate int xyz(float x);
xyz = Thing.pdq;
xyz += o.abc;
xyz(27.3); // I think this will return the result of calling o.abc(27.3)
Pretty handy.
--
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:
> Pretty handy.
Actually, what's annoying is that a null delegate doesn't just do nothing
when you invoke it. I've never seen a delegate invoked that wasn't guarded with
if (myptr != null) myptr(...);
Stupid design flaw there, methinks.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> * This is why, if a Haskell function takes any functions as arguments,
>> they invariably come *first*, and any data structures come *last*. ;-)
>
> Hmm, this is just a convention, I guess. There's no technical
> limitation for a function not appearing last in the argument list.
Oh, sure. Purely a convention. But currying is the reason why this
particular convention is there. That's all I'm saying.
>> Yeah, looks like in about 8 years or so C# or Python or Ruby will have
>> stolen everything that is cool about Haskell, and Haskell itself
>> *still* won't be popular. :-(
>
> Well, C# can because Microsoft employs the father of Haskell. ;)
Well, actually *anybody* who's read about how Haskell works can copy its
design. (Although *implementing* it well is non-trivial...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Technically, I would think you could have a curried function in a
> language with named parameters pretty easily.
Yeah, I don't see why not. It's only a shortcut for creating a closure...
>>> Lambda expressions are darned convenient. I used them in my little
>>> FFT toy app:
>>>
>>> RealInput.Data = GenerateWave(x => cos((Math.Pi*2*x)/(DataLen-1)));
>>
>> They're also damned useful when you want to curry a function:
>> bar = foo (...my random lambda function that I only just here...)
>
> That's where they're used in C#.
I didn't think C# had curried functions like my example.
> This is how the mechanisms for
> querying SQL from C# work - you can write something like
> db.table["customers"].select(x => x.Name > "Henry")
> and the "select()" function takes the AST describing that condition,
> translates it to SQL, and sends it to the database.
Lisp would be proud.
Does this transformation happen at compile-time or runtime?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> class Thing {
> static public int pdq(float y) { ... }
> public abc(float z) { return (int) (z*this.stuff); }
> int stuff;
> Thing() { stuff = 28; }
> }
> Thing o = new Thing();
> delegate int xyz(float x);
> xyz = Thing.pdq;
> xyz += o.abc;
> xyz(27.3); // I think this will return the result of calling o.abc(27.3)
> Pretty handy.
What if you want to call the function (through the pointer) for different
objects? I mean like you would write in C++:
Object obj1, obj2;
obj1.*funcPtr(param);
obj2.*funcPtr(param);
The same member function is called, but for different objects. (Thus if
the function in question eg. changes the state of the object, it happens
to the specified object.)
Curiously, you can even have pointers-to-member-variables in C++, and you
can then dereference the pointer on a per-object basis. That gets pretty
confusing pretty quick.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Transparently.
> e.g.
> delegate void myDel(int x);
> class SomeClass
> {
> public int myValue;
> public void DoInstanceStuff(int x)
> {
> myValue = x;
> }
> public static void Main()
> {
> SomeClass c = new SomeClass();
> myDel d = c.DoInstanceStuff
> d(6); // this sets c.myValue to 6;
> }
> }
So you can't use the same function delegate for calling a member
function of two different objects?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> Warp escreveu:
> > The fact is: If a programming language supports types, if it also
> > supports abstract user-defined types, it becomes an order of magnitude
> > more expressive and useful. And abstract user-defined types are objects
> > (in the OO sense).
> But that's within a function composition environment.
Ah, so we avoid being related to the dreaded Object-Oriented Programming
(vade retro) by using different terminology for the same things. Then we
can write long lists of reasons why *our* terms do not *really* mean the
same things as the equivalent OOP terms.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
