I'm missing something in your comment about tagged types - is rainbow doing it wrong? Arc internally uses a vector to represent tagged types afaik, but rainbow uses a custom "Tagged" class. The example you give behaves in the same way in rainbow.
> I'm surprised at the shortness of welder.
It might be cheating to use java's ui libraries - most of the hard stuff is really in there. But at least now there's a way to call all that library goodness right from arc. I'd like to abstract away everything that looks like java so that theoretically, and if we really had nothing better to do, the same arc ui library could be implemented in any other host language providing a ui.
> I'm somewhat uncomfortable with f!show as being equivalent to f.show()
I set up 'defcall so that for a java-object 'thing,
(thing 'method arg1 argn)
is equivalent to the java call
thing.method(arg1, argn);
It seemed the natural thing to do, but it's only the first version ...
> I'm missing something in your comment about tagged types - is rainbow doing it wrong? Arc internally uses a vector to represent tagged types afaik, but rainbow uses a custom "Tagged" class. The example you give behaves in the same way in rainbow.
No, I just got confused with the lack of 'rep in the call* test ^^ Sorry!
(thing!method arg1 argn) feels more natural to me, but I don't have any idea of any potential mismatch in the way java and arc works.
it's true, when you write it that way, it feels more natural. At a first glance though, this means (thing 'method) must return a method-invoker, which then gets invoked with zero or more arguments. It seems like this would add complexity - instead of calling the method, we call to get the invoker and then call it. The question, as always, is whether the increase in readability merits the increase in complexity ... we'll see what happens I suppose.
