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