On cross-platform development, I've always been interested in the idea of control objects (widgets, knobs, etc) that hook up to (conceptually) remote interfaces. I suppose a modern way to say it would be a collection of control/manipulation/display obects that use RPC or Web Services to connect to an interface, and that also are connected to each other by ThingLab-style constraints.
Then you get a very distributed application indeed, where the user is in control -- it's a way to open up a model-view-controller architecture.
In terms of toolkits, of course I always liked The NeWS Toolkit, or did after I'd started to get somewhere with it, and in away it shares some of this design: you could send a method to an object without needing to know where the object lived, at least in principle, whether in the client part of your application or in some display server somewhere. But it wasn't exactly cross-platform :-)
Haruspex, I wonder how many other active Advogatoers are in Toronto?
Someone asked me a question about refactoring code today so I thought I'd share part of my reply.
He was thinking of replacing lots of special-purpose functions (hasCar, hasTractor, hasTruck) with a pair, hasVehicle and getVehicle. This leads to:
if (hasVehicle(Marvin)) {
theVehicle = getVehicle(Marvin);
drive(theVehivle); // or whatever
}
A better idiom, though, might be
theVehicle = getVehicle(Marvin);
if (theVehicle) {
drive(theVehicle);
}
This avoids a number of problems. One is that it can be made thread safe, whereas the first idiom has a race condition. Another is that it's more efficient. Another is that the resulting code is slightly simpler, easier to read and understand, and hence less error-prone.
It does have the down side that tehVehicle has scope outside the test, so you can improve it (in C) with
{
sometype theVehicle;
/* above code goes here */
}
In C++, Perl and other languages there are other idioms for short-lived local variables, of course.
Although my friend's question wasn't actually about vehicles, I should also note that in choosing a new name for refactored code you need to choose a name whose meaning is obvious from the context in which it's used, so that people don't have to go and read the documentation for your function whenever it's called. Not that documentation is a bad thing, but only that program code that's easier to understand is a good thing.
