Darren New <dne### [at] sanrrcom> 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 (especially if you wanted
all the options inside one single class, rather than having one class per
option, which makes retrieving the values of the options more laborious)
and the one which requires most extra writing.

  Yes, I considered many possible solutions when I implemented that command
line parser class, and found that the function (or rather method) pointer
solution was the best, from the usage point of view. The classes derived
from the parser class can be made simple, short and easy to read.

> 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?

  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);

-- 
                                                          - Warp

Post a reply to this message

Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> C# uses delegates, instead.

  How do they work for member functions?

-- 
                                                          - Warp

Post a reply to this message

Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> I remember declaring structs in C being rather weird.

  The problem with C structs is that whenever you want to use them, you
have to say so. In other words, this works in C++, but not in C:

struct Foo { whatever; };

void bar()
{
    Foo foo; // Doesn't work in C
}

  Instead, you have to write:

    struct Foo foo; // Works in both C++ and C

  However, there's a workaround in C (which also works in C++, because of
the backwards compatiblity):

typedef struct { whatever; } Foo;

  Now you can use "Foo" without having to put the "struct" before it every
time.

-- 
                                                          - Warp

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> I don't like the whole OO BS.  Despite being submitted to it daily for 
> the last 20 years or so.  Functional programming and scripting too 
> opened my eyes to a much better model for software programming.

  Yet most functional programming languages support objects in one way
or another.

  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).

-- 
                                                          - Warp

Post a reply to this message

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] sanrrcom> 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