Pit Capitain wrote:

> benny schrieb:
>> Benny is happy to announce his first published piece of software:
>> "FaceToFace" available as gem.
> 
> Very nice. One question: how is the return value of the conversion code
> used?

well you can see it in the examples: it depends on how you register your
conversion method. the last term in the block is returned. it definitely
makes sense to always return the modified object/result of conversion, but
thats not forced by FaceToFace.


> 
>>   MyClass.register_from( YourClass ) do |my, your|
>>        my.message = your.data
>>        my
>>   end
> 

here the modified object is returned (as in myarray << "entry")
perhaps I should talk more about that in the documentation


>> In the near future there will be a Slot class that is meant to be an
>> Interface to most of the core types/classes.
>> 
>> If two classes have a conversion method to/from the same Slot, it will be
>> possible to convert them into each other via this Slot. This should
>> sometimes eliminate the need of direct or multiple conversion.
> 
> I think the name "Slot" could be misleading. (See previous discussions
> about the term "slot" in this mailing list.) Or are you planning to nest
> the name "Slot" in a namespace as in "FaceToFace::Slot"?
> 
yes, I wanted to nest it as FaceToFace::Slot but my english is not the best.
so perhaps you have a proposal for a better name. 

I wanted to describe  something like a transistion between two worlds.  The
object falls into a hole and is suddenly in a world between two worlds,
then it falls through the exit hole and its in another world (the target
world).

Regards,
 benny

-- 
---------------------------------------------------------------------------------------------------
Don't crash when a filter changes the subject of a message which results
in the attempt to remove it from the tree of subject threading messages
failing and the detached child looking for a new parent finding the old
parent as the new parent, which in turn results in the child being deleted
with the old (and new) parent, which is not a good idea, since it is
still referenced.

(Till Adams commit on kdepim/kmail/kmheaders.cpp in HEAD, 6. Jan. 2005)