Hi Slava, Slava Pestov wrote: > > I'd like to see some additional VM cleanups: > > - The VM class should be split up into several objects, with a central > VM object that refers to them (and not the other way around)
I agree in principle, but having revisited the code I think this could be pretty messy without back-references. For example a lot of functions use 'critical_error()' which in turn calls 'factorbug()' which then needs access to pretty much the whole vm. If objects don't contain back references to the vm then it'll need to be passed as an arg to each member function that might error. Another issue is gc_root objects - they're instantiated everywhere which means pretty much every object is tied to the data heap, making it difficult to tease out other objects like the code heap. In fact most of the vm code is pretty tightly coupled which I guess probably makes it smaller than a loosely coupled OO counterpart. In my experience loose-coupling often trades off with redundancy (e.g. in the 'critical_error' case we'd end up with a bunch of less general error functions). I guess that's the essence of why OO designs often get quite big and bloated. I'm walking the code looking for a good plan of attack, but I suspect it could easily amount to a pretty hefty rewrite rather than a cleanup. Hopefully there's some low hanging fruit tho, will let you know what I come up with. Cheers, Phil ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
