On Fri, Mar 18, 2011 at 8:04 AM, Tim Cuthbertson <t...@gfxmonk.net> wrote: > I'm not seeing owen's side of this conversation (specifically this > first quoted part, I never received. this is also the first message > I've seen discussing static typing vs dynamic typing). is it supposed > to be between the two of you or on the mailing list?
Disregard that. I just found the other half of the conversation in that other tiling thread ;) > On Fri, Mar 18, 2011 at 4:07 AM, Oliver Mangold > <o.mang...@googlemail.com> wrote: >> On 17.03.2011 16:23, Jeffery Olson wrote: >>> >>> Encapsulation, low coupling and seperation-of-concerns. These are all >>> valuable patterns that we can leverage here. >> >> Okay, you have a point here. This is certainly the best one can do under >> dynamic typing. >> >> I'm not sure if it is relevant for the specific project, but still I can >> think of situations where it is not possible to run the API-using code >> directly, e.g. if a hook to a signal that will only be raised on user >> action, the interface of the hook call cannot be tested. >> >>> Now, this doesn't negate the need to test a set of bindings to the >>> mutter/gnome-shell C codebase for API churn. What we need is a way to >>> get access to a Looking Glass-like REPL from the CLI, that would maybe >>> fire up a new process with a "sandboxed" gnome-shell session that >>> wasn't actually bound to an xdisplay, but that we could use to verify >>> bindings, etc. This, once again, falls into the "not yet done" >>> category. I don't know the feasibility of such an endevour. There's a >>> possibility to eval javascript code in the current gnome-shell session >>> via dbus, but I haven't explored this much either (and don't know how >>> useful itd really be). >> >> Of course much can be done in principle, but it still will be a lot of work >> for the writer of unit tests. Even if you have this, you still have to bring >> this sandbox environment into a state, where it is possible to call the >> function you want to test, e.g. if you call workspace.get_windows() you >> probably should have some windows open, and if your function only messes >> with windows that fulfill a certain condition (tiled, maximized, specific >> title, ...) you first have to bring a window in the specific state, etc. >> >> I must admit, though, that static typing is not a cure to detect all API >> incompatibilities, e.g. if the behaviour of a method changes but not the >> interface, still it is something I like very much, as for real world >> purposes it finds quite a lot problems simply by compiling. >> >> _______________________________________________ >> gnome-shell-list mailing list >> gnome-shell-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/gnome-shell-list >> > _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list