Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-01 15:21:30

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <908e74+a1qv_at_e...>, William Kempf <sirwillard_at_my-
> deja.com> writes
> >> As best I understand it, main part and major part are effectively
> >> synonymous.
> >
> >Not even close.  You can 3 (just to pick a number out of thin air) 
> >major parts to something, but you can have only one main part.  
> >A "main part" enjoys majority, which by very definition means only 
> >one.  Major does not indicate any sort of majority, only that a 
> >significant amount exists.
> 
> OK, so we are well off topic here. However, your interpretation is
> unfortunately incorrect. Etymologically it would be a 
contradiction, but
> given the varied state of the English language that is perhaps not
> compelling ;-) However, checking both US and UK dictionaries reveals
> definitions of major in terms of majority, main, principal, 
significant,
> greater, and a whole host of other words that, from my 
understanding of
> the English language, mean similar things.

Careful here.  Significant also does not denote a "majority".  
Neither does greater.  All that's denoted is that it's larger (in 
what ever sense) then something else.  Again, something may have 3 
major parts, but only one of them will constitute a majority.

> >I'm not at all convinced you can call it a minority.
> 
> That which is not the majority is, by definition, the minority (ie 
the
> minor part). I believe there is a bit of a debate currently going 
on in
> the US on this very topic ;-)

We can argue language semantics until the cows come home.  It doesn't 
change my stance or my view point.  I also think you can see where 
I'm coming from, so I refuse to nit-pick stuff like this to death.
 
> >Sorry, but I didn't make the suggestion, you did.  Regardless, the 
> >specific uses for a "callback" are for a very narrow set of 
reasons 
> >where "normal" function objects won't suffice.  These reasons are 
> >much more likely to increase the usage of (3), quite possibly to 
the 
> >point of majority.
> 
> This all sounds remarkably hypothetical, and contrary to both common
> theory and practice.

An authoritative statement with no substance.  Not very helpful one 
way or another in this thread.
 
> >> I think you have to be careful with your terminology here: C++ 
does 
> >not
> >> support closures.
> >
> >Neither does it support lambda expressions, yet the terminology 
can 
> >still be applied.
> 
> Sure, we can all apply terminology loosely, the question is to what
> effect? In the case of the Lambda Library it is to good effect. In 
the
> case of closures, I believe not.
> 
> >> If you mean a binding between object and member
> >> function pointer, that is a slightly different thing, although 
it 
> >has a
> >> subset of closure-like properties.
> >
> >Care to explain what subtle distinction you see here?
> 
> http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=closure
> 
> A binding of an object pointer and member function pointer is a 
limited
> case of an expression bound to a calling context. If you have 
programmed
> in languages that have support for closures you will appreciate 
that the
> distinction is not subtle.

No, but the reasoning for you to nit pick here is quite subtle.  What 
I describe most certainly is a closure.  It just doesn't encompass 
the full set of uses of the term.  I see no reason for your argument 
in my use of the term here, especially since I qualified what I meant 
in my description.

> >The binding may not be modified, but the state of the function 
object 
> >is.  This is no different than a traditional function object built 
to 
> >accumulate the results of a calculation on every member of a 
> >container.  The binding isn't modified there, but you put this in 
> >category 3.  There truly is no difference here.
> 
> There truly is. Some of the commonest such bindings, eg event-based
> callbacks, use pointers rather than objects by value.

This makes little difference.  So the modification of the state is 
indirect instead of direct for some cases, this doesn't eliminate the 
problem.
 
> >> Most of my previous posts
> >> have tended to put forward multiple points of view, and then 
argue
> >> through each, rejecting positions as inappropriate. It appears 
you 
> >have
> >> been picking on the rejected positions or some statement in them 
and
> >> arguing against the position, sometimes for the same reasons!
> >
> >I don't see it that way at all.  We truly are on different wave 
> >lengths here.
> 
> I can only speak for myself, but my own inclination is to try to 
work
> towards consensus rather than contradiction.

That would be the inclination of any sane person so I'm willing to 
bet that's what we're all doing here.  Do you honestly think other 
wise?

> >Again, these operations can not be accounted for by the library.  
> >They are outside the library.  They do not apply, at all, to the 
> >discussion at hand, 
> 
> Surely you are contradicting yourself? These operations are as 
relevant
> to the discussion as threads, which are also not supported in the
> library. Sure, if you don't want to discuss threading any further 
that's
> OK, but I happen to regard it, and other facilities associated with 
it,
> as quite important.

No, I'm not contradicting myself. This is clear in the remainder of 
the quote you split here...

> >to wit, can we implement a callback concept 
> >that's thread safe using cloning with out having intrusive 
> >requirements on the wrapped function objects.
> 
> Is this a question or a statement? If it's a statement (ie "we 
can"),
> then I am in agreement (because that was what I posted what seems 
like a
> long time ago). If it's a question, then the answer is yes.

No, the answer is not yes.  *shakes head*  Sorry, but at this point 
I'm stuck just arguing in circles because we've got an obvious 
disconnect in communication that I can't see how to get around.  Read 
what I've said in previous posts again to try and see my point.

> >Actually, transparent sharing in this case is much less of a 
problem 
> >than deep copying.  The callback can't insure any sort of thread 
> >safety for the copy process when a deep copy is performed, while 
it 
> >can be insured for shallow ref-counted copies.
> 
> I believe you have this back to front. Perhaps you would like to
> demonstrate what you are thinking with a code fragment -- English 
does
> not seem to be serving us well ;->

A deep copy requires copying of all state that may be contained 
within a function object.  This copying of state must be thread safe 
in order for the copying of the function object to be thread safe.  
These state objects are not a part of the function object library, 
but are data types created by the programmer outside of the library.  
Thus the library can not gaurantee that copy of these state objects 
is thread safe.  Thus the library can not gaurantee that copying the 
function object is thread safe.

A ref-counted function object doesn't do a deep copy, so it can 
gaurantee that copying the function object is thread safe (it only 
needs to insure that the ref-count and the wrapped function object 
pointer are handled in a thread safe manner).

This path of arguing would thus lead us to a ref-counted 
implementation instead of a cloning implemtation.  However, I don't 
think that's the right answer.  First, nothing says that we must (or 
even should) gaurantee thread safety here.  Second, I believe in one 
of the arguments that's been brought up, and that you've agreed with 
as well, to wit such functionality can be built on top of a concept 
that uses cloning.  So, I believe we should stick with the basic 
concept, i.e. cloning, and build anything else required on top of 
this.

Bringing thread safety into this discussion is only partially 
appropriate (we must insure that thread safety can be achieved at 
some level of abstraction in the implementation of the concept).  
Doing so, and making it the sole goal as has seemed to be the case in 
this thread, leads me to a different conclusion from the one you're 
trying to make.

Bill Kempf