FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Package hierarchy
Goto page 1, 2  Next
 
Post new topic   Reply to topic     Forum Index -> Sinbad
View previous topic :: View next topic  
Author Message
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sun Apr 25, 2004 1:50 pm    Post subject: Package hierarchy Reply with quote

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
View user's profile Send private message Visit poster's website
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Mon Apr 26, 2004 10:49 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Mon Apr 26, 2004 3:37 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Mon Apr 26, 2004 3:47 pm    Post subject: Reply with quote

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. Smile 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
View user's profile Send private message AIM Address Yahoo Messenger
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Mon Apr 26, 2004 4:04 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Tue Apr 27, 2004 2:18 am    Post subject: Reply with quote

Does OGRE have many friend statements?
Back to top
View user's profile Send private message Visit poster's website
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Tue Apr 27, 2004 4:46 am    Post subject: On repository hierarchy Reply with quote

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
View user's profile Send private message Visit poster's website
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Tue Apr 27, 2004 12:08 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Wed Apr 28, 2004 2:51 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Wed Apr 28, 2004 3:28 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address Yahoo Messenger
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Fri Apr 30, 2004 1:31 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address Yahoo Messenger
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Thu May 06, 2004 5:29 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Fri May 07, 2004 5:42 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Fri May 07, 2004 10:33 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address Yahoo Messenger
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Fri May 14, 2004 8:46 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Sinbad All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group