i mean, i like the idea in theory, but it (cont'd)

raises some questions about what the API should be like. on one hand,
something with full-fledged automatic bridging like Nu gives the users
the full power of ObjC and Cocoa. on the other hand, it basically
exposes implementation details so that we cant change internal class and
method names without breaking anyone's configs who relies on them.

one solution is to just try to design the classes best we can, and move
on. i dont like that solution. its not flexible enough to adapt to chagne.

another solution is to make a set of "facade" classes that mirror the
internal ones. the obvious problem would be the duplication. (now im not
afraid of a little duplication here and there in times of real need, but
this seems like asking for trouble.) but more importantly it raises
questions about param/return types, and who would be using this.

one of the main problems with the current internal classes is that we
try to expose them to the lower-level APIs directly, but honestly thats
not realistic. for one thing, naming conventions have to be worked
around anyway, so naming my method -doFn:after: will need to be
rewritten to be idiomatic in whatever language (in ruby its just #after
and it takes a block). so it seems like designing the internal classes
to be accessed from the scripts is a dumb idea in the first place.

another solution, kind of a compromise, is to create a small "bridge
description" format that explains how to create "facade" classes in that
language and what they map to in the backend. so in Ruby we could have a
hash of of ruby-names to objc-names, and then just do a bunch of
rb_define_class/rb_define_method at setup-time. i like this idea, but im
not sure it will actually work in all the languages. itll work for Ruby
and Nu, probably Python, but i dont know about JSCore. i remember there
being some awful magic required there, like a method-missing kinda
feature being the only way to generate methods in it. hopefully i was
just not looking hard enough and there really is something better.

there's a related but semi-independent problem of types. if we
auto-generate methods to correspond to the real ones, does this mean we
can just use scalars and such in the backend, ie SDWindowProxy etc? if
so that would be lovely, and i think with a little extra work in the
ruby frontend its already possible. but its gonna require some careful
planning to not break backwards compatibility (much).