Yes - this was the one major benefit that I could think of when I wrote my original reply. But once you've exposed the data in question to the scripting language of your choice, you gain quite a bit: - By attaching validation routines and the like in your scripting layer, you can tune these without having to rebuild your program, or even restart it if you're lucky. - You can plug data and validation routines into UI elements using your UI design tool! - You can also expose the resulting bindings at the application level for things like scripting support.
The majority of my validation occurs in the logic layer of my applications. I don't usually put validation code in the GUI unless it is absolutely necessary, and then I usually design a special control (or a special validation object if the native GUI platform supports that type of idea). Even when I do that, the real validation still happens in the logic layer. I don't ever let my GUI access the data members of my logic layer directly. Perhaps this is why I would like the type of framework I described last week, and why I rather like Apple's Cocoa framework (even though I don't get to use it that often). So, a large use case for a higher level language to manage this code isn't useful for what I want, but some of it still is. It might be nice to use a high level script language to put in GUI dependencies (like, hide/show and enable/disable). But, its simple data binding and event handling I'm really looking for. I want less code if possible. Jared McIntyre