Package hierarchy

larsivi · Posted: Sun Apr 25, 2004 1:50 pm Post subject: Package hierarchy

before creating too many files, we should think how the code hierarchy should be built up. Since dirs from some level need to be part of the module name, we can't do it the same way is in C++ with 'include' dirs and whatnot.

I suggest that we have a base directory (which corresponds to the directory 'ogrenew' in my ogredist). In the base dir we have dirs named
sinbad (ogre), platformmanagers, samples, etc. Thus the main modules
will have module names like sinbad.root; sinbad.scenemanager; etc

And from what I'm looking at the moment:
module samples.common.exampleapplication;
(In the OGRE dist the hierarchy is ogrenew/samples/common/src/exampleapplication)

Thoughts?

csauls · Joined: 27 Mar 2004 Posts: 278

Sounds right to me. Would be good to look into how some things might get grouped as well. Here's a thought: could we try to work out the object hierarchy, and build a package containing only blank classes? Ie, a bunch of files containing things like:

larsivi · Posted: Mon Apr 26, 2004 3:37 pm Post subject:

csauls · Joined: 27 Mar 2004 Posts: 278

csauls · Joined: 27 Mar 2004 Posts: 278

Another concern: friends. I'm thinking it may be a good idea to use Ogre's one-major-class-one-file approach... but then how shall we handle uses of C++'s "friend" keyword?
_________________
Chris Nicholson-Sauls

larsivi · Posted: Tue Apr 27, 2004 2:18 am Post subject:

Does OGRE have many friend statements?

larsivi · Posted: Tue Apr 27, 2004 4:46 am Post subject: On repository hierarchy

I've taken the liberty to add the base directory to the repository. When you check out now, you will get:

[working dir]/sinbad

I also have a suggestion for the further dirs:

sinbad/src/sinbad # sinbad main engine dir
sinbad/src/platformmanagers/gtk
sinbad/src/rendersystems
sinbad/src/samples/common
sinbad/src/samples/gtkdemo
...

sinbad/docs # sinbad documentation dir
...

I'm ready to commit the above dirs to the repository if anyone agrees.

csauls · Joined: 27 Mar 2004 Posts: 278

larsivi · Posted: Wed Apr 28, 2004 2:51 pm Post subject:

On the copyright notice:

I guess we'll use the LGPL license (since OGRE use that one).
As for who holds the copyright, is it Sinbad since he wrote the original code? Do we add our names since we've refitted it to D? Do we make a clean room implementation of the OGRE API? (Way too much work!)

csauls · Joined: 27 Mar 2004 Posts: 278

I may fire off a message to Steve and see how he feels about the copyright, since its primarily his baby... meanwhile I'll put forward the following adaptation of OGRE's notice...

csauls · Joined: 27 Mar 2004 Posts: 278

Back to the topic of friends, I may yoink a copy of Axiom (the C# implementation) and see what it did about the Root<-->RenderSystem relationship.
_________________
Chris Nicholson-Sauls

csauls · Joined: 27 Mar 2004 Posts: 278

Well I did look at Axiom... and once I got over the initial headache of reading C# code, I figured out they they've simply coded around the issue instead of trying to grant any special access to RenderSystem. It looks like they moved some things over to a utility class or something... I'm not C# savvy. They also renamed Root to Engine, which took me a while to realize.
_________________
Chris Nicholson-Sauls

larsivi · Posted: Fri May 07, 2004 5:42 am Post subject:

After looking at Root.h/cpp and the RenderSystem docs I don't understand why they need the friendlyness. At least in that place, I believe that it must be possible to find acceptable solutions without compromising about the 'one class per file' philosophy.

csauls · Joined: 27 Mar 2004 Posts: 278

It could possibly be a stray bit of legacy from Steve's initial project. No way to know. Alright then, we're sticking with one-major-class-one-file. Will try to get an initial set of "blank" files into Subversion soon.
_________________
Chris Nicholson-Sauls

csauls · Joined: 27 Mar 2004 Posts: 278

I was finally able to get back to work on these "blank" source files -- although calling them blank is a bit misrepresentative since I'm going ahead and tossing in our current choice singleton code for the appropriate classes. But in the process, I've ran into a couple of things.

First off, I guess we may as well join the trend and go to the /branch;/tag;/trunk format for SVN. Second, I'd like to do away with /sinbad/src entirely, moving all its contents to /sinbad.

Third times a charm... or major decision in this case. To illustrate this snag, I'll speak of it in terms of three of the classes used to work with Materials: MaterialManager, MaterialSerializer, and Pass.

------------------------------

Option #1: Stick with OGRE style. This means having the following:
/sinbad/sinbad/materialmanager.d
/sinbad/sinbad/materialserializer.d
/sinbad/sinbad/pass.d

------------------------------

Option #2: Subdivide for object types. This means having:
/sinbad/sinbad/managers/material.d
/sinbad/sinbad/seralizers/material.d
/sinbad/sinbad/pass.d

The issues with this one: pass isn't obvious. Would could possibly put all the material-component classes into one module -- /sinbad/sinbad/material.d -- but I'd like not to if possible. There are other managers/serializers however, so the division isn't arbitrary. The root class for managers, in this case, is /sinbad/sinbad/managers/resource.

------------------------------

Option #3: Subdivide for systems. This means having:
/sinbad/sinbad/material/manager.d
/sinbad/sinbad/material/serializer.d
/sinbad/sinbad/material/pass.d

I thought of this one somewhat belatedly, but am leaning toward it. It makes the relationship much more clear, in my eye. In this case the root for the managers is /sinbad/sinbad/resourcemanager or just /sinbad/sinbad/manager.

------------------------------

Thoughts?
_________________
Chris Nicholson-Sauls