"Gregor N. Purdy" wrote: > > Jeff --- > > > Rather wordy, I know, but it also points out how many places depend upon > > the name 'core' in the current code. > > > > I'm also posting a different version shortly that combines core.ops and > > vtable.ops into one core_ops.{c,h,pm}. > > Are the vtable ops supposed to be considered 'core' ops? I'm hoping this > is just a temporary hack due to our lack of full platform support for > dynamic loading...
I never intended it to be anything but. The lack of loading vtable ops was blocking so many things that I felt we had to get something done, regardless of how ugly it appears. I'll work on the "right" way to do it, but in the interim, something had to be done. > This sounds like a step backwards. If we could get enough folks to make > sure we've got the correct platform support for dynamic loading, we can > write the real code, which will know how to load up an oplib on the fly, > which is much better (IMHO). I started on this stuff, but it didn't > seem like we had our act together enough yet on the platform stuff, so > I put it on hold while that was dealt with. Yeah, it's a step backwards in one sense, so I have no problem with having this code ripped out when a real replacement comes out. > I wonder if there's enough interest to just go ahead and do this right > (read: separate oplibs with dynamic loading) sooner rather than merge > these oplibs together? I'm already thinking about the right way to do this, and will hopefully submit a new set of patches once I get some more info about dynamic loading on Windows. > Regards, > > -- Gregor