On 11/9/06, Robin Garner <[EMAIL PROTECTED]> wrote:
Geir Magnusson Jr. wrote: > > > Weldon Washburn wrote: >> >> >> On 11/8/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> >> >> Weldon Washburn wrote: >> > On 11/7/06, Ivan Volosyuk < [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> >> >> On 07 Nov 2006 14:35:55 +0600, Egor Pasko <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> > > I already have one idea how to benefit from movable vtables. >> > >> > >> > There would have to be a very compelling argument for making >> vtables >> > movable. Like a business workload that Harmony needs to run >> within the >> > next >> > 12 months. >> >> How would a business workload need this directly? >> >> That's the point. I can't figure out any compelling story for moving >> vtables. As far as I can tell, its over-engineering. I would love >> to be proven wrong. > > But isn't this simply an implementation detail of something that is > important, namely the class unloading? > > geir
I have no problem calling it an implementation detail. Its an important implementation detail that somehow got mixed into the design conversation. Worth noting is that ultimately the committer is on the hook for committing an implementation. It would be good to have the discussion on moving vtable implementation before someone spends a bunch of time on it. While it did come up as an issue in the class-unloading talks I think
most of us believe it to be orthogonal. cheers -- Robin Garner Dept. of Computer Science Australian National University
-- Weldon Washburn Intel Enterprise Solutions Software Division
