View previous topic :: View next topic |
Author |
Message |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
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? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
csauls
Joined: 27 Mar 2004 Posts: 278
|
Posted: Mon Apr 26, 2004 10:49 am Post subject: |
|
|
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:
Code: |
class AbstractSceneNode {
}
class SceneNode : AbstractSceneNode {
}
|
In this way, the whole lib could be technical "complete" just not entirely implemented. Then when we get to the point of writing real code, we can jump straight to where it needs to live, edit it in, write some sort of test (unittests?) and commit it. And for now we'll be able to see directly what our layout will feel like to application code. _________________ Chris Nicholson-Sauls |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Mon Apr 26, 2004 3:37 pm Post subject: |
|
|
csauls wrote: | 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:
Code: |
class AbstractSceneNode {
}
class SceneNode : AbstractSceneNode {
}
|
I think that I agree. Maybe we should get the repository up and running and submit it there?
In this way, the whole lib could be technical "complete" just not entirely implemented. Then when we get to the point of writing real code, we can jump straight to where it needs to live, edit it in, write some sort of test (unittests?) and commit it. And for now we'll be able to see directly what our layout will feel like to application code. |
|
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
csauls
Joined: 27 Mar 2004 Posts: 278
|
Posted: Mon Apr 26, 2004 3:47 pm Post subject: |
|
|
larsivi wrote: | I think that I agree. Maybe we should get the repository up and running and submit it there? |
Let's get comments into the style guide and invent a license notice to stick at the top of files, then I'll bug Brad for a repository. Would also be good to keep a to-do file in the repository, so whenever someone updates they can see explicitly what's higher priority.
Edited to note: Okay, scratch part of that... he went ahead and set it up without being asked. Thanks Brad! _________________ Chris Nicholson-Sauls
Last edited by csauls on Mon Apr 26, 2004 4:30 pm; edited 1 time in total |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
csauls
Joined: 27 Mar 2004 Posts: 278
|
Posted: Mon Apr 26, 2004 4:04 pm Post subject: |
|
|
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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Tue Apr 27, 2004 2:18 am Post subject: |
|
|
Does OGRE have many friend statements? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
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. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
csauls
Joined: 27 Mar 2004 Posts: 278
|
Posted: Tue Apr 27, 2004 12:08 pm Post subject: |
|
|
larsivi wrote: | Does OGRE have many friend statements? |
How many I couldn't say. I came across the one in Ogre::Root -- friend RenderSystem; -- and started scratching my head. We'll probably just have to drop friends altogether and explicity bridge objects together. Its either that or make the abstract render system object live in Root's module, but A) that's not good encapsulation, and B) I don't know if child classes would inherit the friendship status.
larsivi wrote: | I'm ready to commit the above dirs to the repository if anyone agrees. |
Go for it. _________________ Chris Nicholson-Sauls |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
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!) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
csauls
Joined: 27 Mar 2004 Posts: 278
|
Posted: Wed Apr 28, 2004 3:28 pm Post subject: |
|
|
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...
Code: |
/*
***********************************************************************
* This source file is part of Sinbad.
* Sinbad is a re-implementation of OGRE in the D Programming Language.
*
* OGRE (Object-oriented Graphics Rendering Engine)
* Copyright The OGRE Team
* http://www.ogre3d.org
*
* The D Programming Language
* Developed by Walter Bright / Digital Mars
* http://www.digitalmars.com/d
*
* See further acknowledgements in Readme.html
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU Lesser General Public License as
* published by the Free Software Foundation; either version 2 of the
* license, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this program; if not, write to:
*
* Free Software Foundation, Inc. Boston, MA 02111-1307
* 59 Temple Place
* Suite 330
* Boston, MA 02111-1307
* USA
*
* Or go to:
* http://www.gnu.org/copyleft/lesser.txt
***********************************************************************
*/
|
_________________ Chris Nicholson-Sauls |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
csauls
Joined: 27 Mar 2004 Posts: 278
|
Posted: Fri Apr 30, 2004 1:31 pm Post subject: |
|
|
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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
csauls
Joined: 27 Mar 2004 Posts: 278
|
Posted: Thu May 06, 2004 5:29 pm Post subject: |
|
|
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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
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. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
csauls
Joined: 27 Mar 2004 Posts: 278
|
Posted: Fri May 07, 2004 10:33 pm Post subject: |
|
|
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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
csauls
Joined: 27 Mar 2004 Posts: 278
|
Posted: Fri May 14, 2004 8:46 am Post subject: |
|
|
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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|