Um,
I believe you're saying "supplying a smaller subset of the functionalities of Scene", as being able to supply something else than a concrete implementation should never really be a problem - in fact, in most cases supplying an interface is more desirable. That said, what I was advocating, is that what is now Scene, probably could do well with an overhaul, and an explicit enumeration of what a "Scene" implementation really needs to provide, on one side as a contract with the core, and on the other side, as a contract with the module API. I believe that those things should probably look (subtly or radically) different. Not to _hide_ core functionality from the module, but to provide _tailored_ functionality, enumerated for smooth decoupling and encapsulation. Best regards, Stefan Andersson Tribal Media AB > Date: Tue, 14 Apr 2009 20:32:48 +0200 > From: mela...@t-data.com > To: opensim-dev@lists.berlios.de > Subject: Re: [Opensim-dev] Supplying IScene instead of Scene for the future > region modules mechanism > > I'm not happy with supplying IScene. It would basically curtail the > functionality of region modules to what core believes should be > possible, and will lead to ugly upcasting "(Scene)IScene" that the > code is already rife with. > So, I'm not seeing that as a good idea at all, it limits things too > much. > > Melanie > > Justin Clark-Casey wrote: > > Hey Homer (since this is primarily addressed to you :), > > > > I see you're making some progress on the up-and-coming new region modules > > mechanism. > > > > Instead of passing Scene itself to region modules, could we create an > > interface so that we better control the amount of > > innards that we expose to region modules? It's convenient-ish to give the > > original Scene class to modules now, but it > > will cause us problems down the road. > > > > I'm quite happy to pitch in with this if you want. I suggest renaming the > > existing IScene to ISceneBase (since that's > > what it really is) and creating a new IScene that's implemented by Scene. > > > > It strikes me that it's going to be more convenient to do this when we > > introduce the new system than as a separate change. > > > > Thoughts? > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev