Re: VFS: C99 sparse format for struct vfsops

From: Paul Richards (paul_at_freebsd-services.com)
Date: 06/03/03

  • Next message: Poul-Henning Kamp: "Re: VFS: C99 sparse format for struct vfsops" 
    To: "M. Warner Losh" <imp@bsdimp.com>
Date: 03 Jun 2003 00:00:02 +0100

    On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote:
    > In message: <1054590840.1641.12.camel@cf.freebsd-services.com>
    > Paul Richards <paul@freebsd-services.com> writes:
    > : The possible methods available in an interface are fixed, they're
    > : defined in the .m files.
    >
    > No it isn't. One can add additional interfaces at any time without
    > breaking binary compatibility, so you don't know, a priori, the number
    > of methods in a given interface when you build a client of that
    > interface.

    I don't think that's true.

    The interface is defined in the .m file and it's created using makeobjs.
    You can't do that at runtime because it creates the kobj_desc struct
    that uniquely represents the existence of that method globally for the
    whole of the kobj subsystem. The set of all kobj_desc defines all
    possible methods that can be implemented by an object, and yes you can
    extend that interface later and previously built modules will still work
    because they only implement a subset of those possible methods, but the
    set of all methods that can exist is determined at compile time from the
    interface definitions

    A class is then defined which specifies the set of methods that objects
    instantiated into that class *can* implement (but are note required to).
    The set of methods in a class is also fixed, since it's basically the
    method table plus some class fields and the method table is created at
    compile time. Again though, if you later extend the class older compiled
    modules will still work because if the method doesn't exist in that
    older module the default from the kobj_desc will be used or the
    kobj_error_method will be called (which is safe).

    So yes you can extend the interface and the class and keep backwards
    compatibility but that all happens at compile time, and therefore at
    runtime when the object is instantiated you know the maximum number of
    methods that the object can possibly call. 

    -- 
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]
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Poul-Henning Kamp: "Re: VFS: C99 sparse format for struct vfsops"

    Relevant Pages

    • Re: Using Delphi 2006 to target .NET 2.0
      ... The same way compliance to an interface or class is resolved. ... constraint) will be done at compile time. ... have the methods defined in the constraint for MyList. ... MyType is not an interface, ...
      (borland.public.delphi.non-technical)
    • Re: VFS: C99 sparse format for struct vfsops
      ... and yes you can extend that interface later and previously ... >> table is created at compile time. ... Again though, if you later extend ... instantiation time, why isn't allocating a fixed array appropriate? ...
      (freebsd-current)
    • Re: Subclasses in interfaces
      ... > basic purpose of an interface" to use it only to define constants. ... > final for its value to be substituted at compile time. ... not the entirety of what enums are about. ...
      (comp.lang.java.programmer)
    • Re: Subclasses in interfaces
      ... I'm not specifying an implementation of ... that does not specify a contract in the terms you are thinking. ... purpose of an interface" to use it only to define constants. ... for its value to be substituted at compile time. ...
      (comp.lang.java.programmer)
    • Re: Using ITypeComp: unable to look up methods or properties when return type is an IDispatch.
      ... Obviously ITypeComp can't tell you more than the original component ... weakly type her interface, there's nothing you can do at compile time - ... There exist automation interfaces where weak typing serves a purpose. ...
      (microsoft.public.win32.programmer.ole)