From: benny <listen@...>
Date: 2005-02-16T17:09:58+09:00
Subject: Re: [ANN] FaceToFace 0.1.0

Alexander Staubo wrote:

> benny wrote:
>> FaceToFace aims to standardize the conversion and messaging
>> between classes and objects.
> 
> By the usual nomenclature this is an adapter framework -- why not call a
> spade a spade? :)
thanks for the info: I didn't knew that ( being musicologist ).
so a will rewrite the gems-description

> 
> Looks elegantly implemented, though. Ruby definitely needs something
> like this as part of the core.
thank you. perhaps we can implement a gem-like central register of
conversion libs using FaceToFace and this way autmagically install a
required conversion lib, if the method is used but the conversion method is
not there (comparable to require_gem).

> 
>> In the near future there will be a Slot class that is meant to be an
>> Interface to most of the core types/classes.
> 
> I agree with Pit Capitain that the term "slot" is overloaded. Can you
> give an example of your Slot class and its usage?
> 
> Alexander.
If you hava an idea about a better name. please let me know.

well, it will be some magic behind the scenes. you register the conversion
methods between the "slot" and other classes as usual (but using other
registering methods) and then you convert for example between class A and B
without having registered any direct  conversion between them

t = Slot.new( slot_name, struct)
t.register_slot_from( A ) do |a, slot|
.....
end

t.register_slot_to( B ) do |b, slot|
.....
end

a.to! ( B ) #=> searching for direct conversion methods, if not there
searching for common "slots" and convert via the first common slot

or 

a.to( B, slot_name) #=> explicitely convert via slot "slot_name"


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