On 13/08/2014 16:39, Jim Starkey wrote: > You are now quite close to COM. The primary difference is that COM is based > on immutable interfaces and you have a single squishy interface with explicit > interface version. After a few iterations, developers with have to track > what versions had which features to avoid calling things that don't work. > This puts a large burden on programmers and, what's worse, there's really no > way to determine whether a program that works with one version will work with > another. > > COM's immutable interface model means that if an object supports an > interface, it supports it completely and safely without manual checking. If > a plugin requires backward compatibility, it can probe for interfaces it > understand and use the best. If it can't find an acceptable interface, it > knows it can't continue. > > I question whether you have really thoughtful how an interface is going to > grow and evolve. At best, you are limiting the ability for future Firebird > developers to implement new functionality in an upwardly compatable manner.
It's in the design that we can't grow base interfaces, but we surely can grow leaf ones. You do not wanted to hear or look how non-manual version checks works. > Many, many projects have looked at the same issue and decided that multiple, > immutable interfaces are the way to go. None, other than Firebird 3, has > decided to re-invent objects with a decidely weak mechanism for growth. > List of projects using COM? And as I said, if you want a full-bloated approach for nothing or for integration, then there may be a COM wrapper generator. While I don't tried, I see no reason it would be impossible. Adriano ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
