From: Gerrit V. <vo...@ca...> - 2006-08-26 03:52:59
|
Hi, On Fri, 2006-08-25 at 22:35 -0500, Dirk Reiners wrote: > Hi Gerrit, > > On Sat, 2006-08-26 at 11:18 +0800, Gerrit Voss wrote: > > > > If we do something that involves changing basic things (like the FC > > > naming scheme), I would like to get it decided before 2.0 beta. > > > > my notion would be more extending than changing, having an optional > > libname: in front of the fieldcontainer name should not screw up any > > existing code. > > Hm. Yes, I guess that would work, too. It would mean that an app can > either bind explicitly and just expect the FC type to be loaded already > (and use just the name), or they can provide the libname and the system > will load the lib if it's not loaded already. I would still > enforce/assume unique names across libs (no foo:bar and baz:bar) to keep > things simple. ok the usual me too. > > I'm a little bit undecided whether to use something we must search for > > in every fieldcontainer name or if we should use something like > > @libname:class, which is a little bit less readable than the pure : > > version but still can be seen as having a meaning like > > 'at libname find class' ;-) And we can decide on fcName[0] what > > to do. > > I don't mind that very much, but I don't think it would be a big > problem. Looking for a character in a string that is processed and > compared anyway shouldn't be a big deal. I'm always a little bit hesitant on string stuff, having seen its contribution to the NP completeness of some AI problems (rewriting and reasoning IIRC, way to long ago ;-) ). Anyway another fancy idea would be to find a way not only to load FCs but to load them and have them override a stored prototype core. regards, gerrit |