OTP design

[Chris Pressey]

On Thu, 13 Jun 2002 15:32:35 +0200
"Vlad Dumitrescu" <vlad.dumitrescu@REDACTED> wrote:

> Hi,
> 
> I was thinking about the way OTP is designed and came up with some
> questions/proposals:
> 
> - there are some parts that seem to me to be possible to "open up" in
> order to allow different implementations to be plugged in. One example
> is the code module, where Joe had to hack it in order to make SAE
> working, but other ways to handle that might be envisaged. Another is
> GS, where the backend should be possible to switch to a non-TclTk one.
>   Is fixing this something to be considered? Do you think it needs to be
> "fixed"?

As someone who has considered writing a different backend for GS (it's
still a loooong way away, though,) there are two unelegant ways I can see
it being used:

- user renames gs_gtk.erl to gs.erl; or
- user uses Igor (or similar) to change all occurances of gs: to gs_gtk:.

I guess one other possibility could be to have a directive like

  -import_as(gs, gs_gtk).

Which is probably so similar to something Igor already does (working as a
parse transform) that it's not worth considering as a solution seperate
from Igor.

But something along those lines would be the way to go, I think.  It would
be nice to seperate the interface from the implementation, and to
re-associate them in the calling code.  So 'gs' would be an interface. 
'gs_tcltk', 'gs_gtk', 'gs_qt' (etc) would be implementations.  Calling
code would still call gs:whatever, but would indicate what module they
would like to implement the GS interface.

-Chris