Re: [boost] Re: New New Callbacks Uploaded

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-12-01 13:53:35

In message <908e74+a1qv_at_[hidden]>, 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.

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

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

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

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

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

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

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

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

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________