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

Benny is happy to announce his first published piece of software:
"FaceToFace" available as gem.


Dear list,

I hope this is useful for someone and I am curious what you think about it.

The code itself is no big deal and always open for improvements (as my
english is).

= Overview

FaceToFace aims to standardize the conversion and messaging 
between classes and objects. 

You may think of it as syntactic sugar and as duck-typing taken to 
the next level (imagine two ducks face to face, none of them being a real
duck).

Up to now we had to remember each method that converts to a 
certain class, e.g. 'to_i' converts to Integer, 'to_s' converts to String
etc.

With FaceToFace you only have to remember one method and 
you need to know the class to convert to, e.g.
  5.to(String ) #=> "5"
  "6".to( Integer ) #=> 6

That way you could double-ducktype, i.e. you may not care 
about the class of any object you convert to or from, e.g.
  def double_duck_me( duck1, duck2 )
      duck1.to( duck2.class_name )
  end

Instead of using to() you could also use from() to access the result of a
conversion, e.g.
    Array.from( "test" ) #=> ["test"]
    String.from( 4 ) #=> "4"

Furthermore you can pass objects instead of classes as well
   5.to( "" ) #=> "5"
   "6".from( 4 ) #=> "4"

This allows you to pass messages between objects and modify them completely
or partially, e.g.
  class MyClass
     attr_accessor :message, :data
  end

  class YourClass
     attr_accessor :message, :data
  end

  MyClass.register_from( YourClass ) do |my, your|
       my.message = your.data
       my
  end
 
  my = MyClass.new
  my.data = "my Data"
  your = YourClass.new
  your.data = "your Data"
 
  my.from( your )  
 #=> #<MyClass:0x806c56c @data="my Data", @message="your Data">

== Benefits

+ Unfied way to define Object / Class conversions
+ Ability to seperate the code of conversion methods from the classes 
  itself for continuous optimization/version-replacement
+ "blind" conversion to/from foreign classes
+ indirect conversion via slots in the future
+  you don't have to invent new methods each time you need to define a
conversion
- maybe performance
- a little more effort to define the conversion methods

== Future

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.

== Installation
gem install FaceToFace --remote

== Example of usage
   require 'rubygems'
   require_gem 'FaceToFace'
   # not needed but recommended (registers to_a, to_s and the like)
   require 'basic_registration' 

  # registration of the conversion methods of self defined classes, e.g.
  MyClass.register_from( YourClass ) do |my, your|
    my.message = your.data
    my.message 
  end
 
  MyClass.register_to( YourClass ) do |my, your|
    your.message = my.data
    your.message
  end

 # You may overwrite singleton methods for objects and classes 
   class MyClass
     def initialize(data)
        @data = data
    end

    def MyClass.from(obj, via=nil)
      FaceToFace::Registry.from( (self.new(obj.message) ), obj, via ) 
    end
  end

  your.message = "your Message"
  MyClass.from( your ) 
 #=> #<MyClass:0x810d8d8 @data="your Message", @message="your Data">

----------------------------------------
Project Website: http://rubyforge.org/projects/facetoface
Contact: linux@marcrenearns.de

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)