Date: Wed, 4 Jun 2003 14:16:28 +0100 From: Paul Richards <paul@freebsd-services.com> To: Doug Rabson <dfr@nlsystems.com> Cc: current@freebsd.org Subject: Re: VFS: C99 sparse format for struct vfsops Message-ID: <20030604131628.GE68108@survey.codeburst.net> In-Reply-To: <1054730025.32554.15.camel@builder02.qubesoft.com> References: <26877.1054676171@critter.freebsd.dk> <20030603.160943.102571653.imp@bsdimp.com> <1054594801.1641.49.camel@cf.freebsd-services.com> <200306041001.07145.dfr@nlsystems.com> <20030604122445.GB68108@survey.codeburst.net> <1054730025.32554.15.camel@builder02.qubesoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote: > Interfaces actually can be added at runtime. Existing objects (i.e. > objects instantiated before the new interface was added) will continue > to work as before. If methods from the new interface are called on old > objects, the default method will be called. How can you add an interface at runtime? All of this runtime activity is theoretically possible, i.e. all these structures can be messed around with to add methods to existing objects etc. but wasn't kobj supposed to provide an OO type abstraction and therefore the interfaces and classes are determined at compile time. I'm not aware of any actual code that changes interfaces or classes at runtime and if we added that functionality then I think it would break the abstraction and complicate the usage of kobj for no real gain. Coming back to the central point, I don't understand why we need a cache at all. I don't see the reason for having to support the dispatching of anything other than the methods in the class that the object was instantiated into, so that means a relatively small fixed size method dispatch table. The only argument for that not working is if the class gets extended after the object is created but I'm not convinced yet that that's something to worry about in practice at least at the moment since we don't extend classes anywhere. Even if we added code to make that possible at runtime it would be simple enough to get a "miss" when looking that method up in older objects and to realloc the method table in the object to accomodate the new methods. Extending the class is something that is likely to be so rare that some performance penalty should that happen would be palatable. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030604131628.GE68108>