From: ahoward <ahoward@...>
Date: 2003-06-19T04:16:12+09:00
Subject: Re: switching multiple interfaces of an object

On Thu, 19 Jun 2003, Mauricio [iso-8859-1] Fern�ndez wrote:

> > care to comment on the relative merits/drawbacks of these approaches?  i really
> > do think something standard like this would be extremely useful.
>
> Ummm, your code is *way cleaner and simpler* :-)

lol.  that's a *first* for me on c.l.r.!  well - ts hasn't responded so
perhaps i've spoken too soon...


> My code basically involves aliasing methods as needed to get the right
> ones to have the required name.
>
> Cons: (w.r.t. delegation)
         ^^^^^
         ^^^^^
         ^^^^^  ??

>  * threading issues: the current interface used for one object must be
>    the same in all threads (or non-interfering interfaces)
>  * more complicated
>  * uses 1 class instance variable (bad in the sense that if you mess
>    with that it breaks :)

how about marshaling?  if you dynamically alias methods - can you marshal
that?

> Pros: (ditto)
> * in your code you have to create internal classes, whereas I am only
>   adding methods and saying "methods foo, bar and baz as defined right
>   now correspond to interface Babar". So I think although the
>   implementation I did is more complicated, its use is actually easier.

but perhaps less safe.  the reason i have all the classes and interface defs
as private is that, only the class designer should, really, know which
different interfaces are possible and what constraints there are (eg.  once
you use interface 'x' the object may not ever be used via interface 'y' -
these situation are not that hard to imagine...)  maybe this is just the evil
c++ side of me coming out?

> * this means your classes don't normally share state unless you do
>   explicitly pass it around (which you do in your code), so it seems
>   more difficult to do this "extend and define interface" thing and
>   don't have direct access to instance vars

i see that.  however, my idea was simply to separate data from methods, and to
let the methods be 'assign-able'.  eg. to switch interfaces.  kind of funny
that oo programming talks about putting data and methods together and here we
go separating them... ;-)  i guess i'm thinking that, although it is certainly
possible to separate methods from data (as i did) there is still a potentailly
*very* tight coupling between the two - thus the private inner class thing...

> * it can be made to work with singleton methods, so they get
>   registered as part of the interface.

in my code, all that would be needed to do this is an

  attr :interface

in other words, you can do this if the interface class is publicly available:

  class << k.interface
    def foo; 'foo'; end
  end

you get the idea...

> * therefore w/ your code interfaces and their implementations have to
>   be known beforehand, whereas with mine it's easier to add them on the
>   fly (Object#extend).

i wouldn't agree here, although it would make the code longer than 51 lines
one could easily design

  class Klass
    def Klass.register_interface interface
      unless @trust
	raise unless has_right_methods interface
	raise unless passes_unit_test interface
	raise unless some_constraint_or_another interface
	raise unless etc interface
      end
    end
  end
...

  Klass.register_interface MyInterface

> You can find the code at
> http://www.rubygarden.org/ruby?AdaptorPattern/Generalized

i'll check it out.

> If there's interest in a such a thing I have a couple ideas which should
> work much better.

i, for one, like the idea alot.  yours may be alot better - i'm just
brainstorming...

-a
--
  ====================================
  | Ara Howard
  | NOAA Forecast Systems Laboratory
  | Information and Technology Services
  | Data Systems Group
  | R/FST 325 Broadway
  | Boulder, CO 80305-3328
  | Email: ara.t.howard@noaa.gov
  | Phone:  303-497-7238
  | Fax:    303-497-7259
  | ~ > ruby -e 'p(%.\x2d\x29..intern)'
  ====================================