sooc-devel

[Sooc-devel] Sooc Documentation

[Daniel R. <sta...@gm...>]

I decided to take a look at your recent sooc updates.  I saw that one thing
you did was to create a functor that takes 2 arguments.  However, the
included documentation, which was probably copied over from s-func1.h, kept
saying it only took 1 argument.  I corrected this and committed the changes.
 Please let me know (and fix it) if I have misunderstood this.
Secondly, and this is the reason why I am sending this message to the
mailing list and not to you directly, 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).

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?

If functors of varying parameter counts are not possible (or important), how
many of these things do you think there ought to be?  Should it just stop at
2 or ought it to go out to 3 or 5 or something?  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.

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

Hope all is well and that your recent work on iterators and memory
management and such has been coming along nicely.  I will look at SMap next.

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