Re: [Sooc-devel] Sooc Documentation

[Mike R. <mik...@gm...>]

On Thu, Jul 31, 2008 at 11:55 PM, Daniel Reinish <sta...@gm...> wrote:
> I was just wondering if there is any way around the need to have
> separate sooc objects for every type of functor (i.e. a new object
> each time a functor with more variables is needed). I'm guessing you
> created SFunc1 when a simple functor was needed and recently created
> SFunc2 due to the need for a pointer to some function with two
> inputs.  These function objects are, of course, useful to have
> around, but it seems *somewhat* arbitrary that functors can only
> support one or two arguments (obviously, these are two of most
> likely argument counts).

Yes, recently I (mistakenly) thought that I would need an SFunc2, so I
ripped off SFunc1 to make SFunc2.  I think it would be reasonable to
include SFunc1-SFunc5.

> My initial suspicion is that this is a limit of C.  I know it's possible to
> have a variable number of same-type parameters (I forget the technical name
> for this) in Java and I'm guessing that if Java can do it, so can C++ (in
> fact, we may have even talked about this before).  I also suspect it would
> be non-trivial to implement such a thing in Sooc, so I imagine that's why it
> has not been done.  Is that indeed the case?  Is it possible at all?  And,
> the big question: does it even matter?

In C and C++, you can have variadic functions (functions with a
variable number/type of arguments) -- think printf().  The trick is
that there needs to be some way of knowing where the argument list
ends.  Maybe you keep looking for integer/string pairs until the
integer is -1, for example.  Or maybe you keep looking for pointers
until one is NULL (like s_retains() and s_releases(), for example).
The point is, C/C++ variadic functions are extremely general, but
consequently they are not type-safe.  Anyway, there should probably be
a SVFunc functor class, but I need to think more carefully about the
design due to the tricky nature of variadic functions.

> This is *clearly* not a priority at the moment, but if you think
> there should be more, I would gladly write them myself, as it would
> not be very complicated to simply copy the code and extend it where
> necessary.

As mentioned above, SFunc3-5 should probably be done.  If you could
handle that, it's less work for me -- good times!

> And one last question.  Why does the pointer message and related method need
> to take the function's parameters as arguments?  It doesn't seem to use them
> since it merely returns a pointer to the function.  Has this been done to
> account for possible subclasses that may wish to re-connect the message to
> some method that does do something with the arguments (although I can't
> imagine what)?

That is exactly the reason.  I'm not sure if that would even be a
reasonable thing to do, though.  Maybe we should discuss that aspect
of the design a little more....  It might be best to drop the argument
list from the pointer method.

-Mike