| View previous topic :: View next topic |
| Author |
Message |
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
 Posted: Mon Apr 26, 2004 8:58 am Post subject: Singletons |
 |
|
There are several singletons in OGRE. I think it is okay to keep 'em as such in Sinbad too, but how should we implement them?
As a module is probably out of the questions, since many of the singletons inherits Root.
Then it needs to be some class. I'll look into the possibilities. As long as we're aware of the 'problem', it's probably no rush. |
|
| Back to top |
|
 |
csauls
Joined: 27 Mar 2004
Posts: 278
|
| Posted: Mon Apr 26, 2004 10:26 am Post subject: |
|
|
I've been thinking about the same thing, and how to deal with it. There's probably a number of ways to do it. One possibility is using private/protected constructors and static instances, probably living at module scope.
_________________
Chris Nicholson-Sauls |
|
| Back to top |
|
|
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
| Posted: Tue Apr 27, 2004 1:54 am Post subject: |
|
|
| I thought a second that the template approach used in OGRE also could work in D, but at some point it will lead to MI. Since Root seems to THE most important class, I now believe that this is one of the problems we should solve first. |
|
| Back to top |
|
|
csauls
Joined: 27 Mar 2004
Posts: 278
|
| Posted: Tue Apr 27, 2004 12:25 pm Post subject: |
|
|
| larsivi wrote: | | I thought a second that the template approach used in OGRE also could work in D, but at some point it will lead to MI. |
Aka something like:
| Code: |
class Root : Singleton!(Root) {
}
|
*nods* It might've worked, if only. Maybe we could do something similar, just at the class level instead of a singleton parent class? Just write them along the lines of:
| Code: |
class Root {
static this() {
_singleton = new Root();
}
public:
static Root singleton() {
return _singleton;
}
protected:
this() {
// ...
}
private:
static Root _singleton;
}
// ... user code
Root root = Root.singleton;
// ... do stuff with root
|
Its pretty short and simple, wouldn't be a hassle to write in where needed.
_________________
Chris Nicholson-Sauls |
|
| Back to top |
|
|
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
| Posted: Wed Apr 28, 2004 9:59 am Post subject: |
|
|
Why the 'static this()'? Just have an if in the singleton getter:
| Code: |
if (_singleton is null) {
_singleton = new Root();
}
|
|
|
| Back to top |
|
|
csauls
Joined: 27 Mar 2004
Posts: 278
|
| Posted: Wed Apr 28, 2004 11:08 am Post subject: |
|
|
Serves the same purpose, really, except the if(){...} will occur later... but it does look cleaner, I'll agree on that. If only interfaces could have static members... then we could have an iSingleton requiring the .singleton() method.
_________________
Chris Nicholson-Sauls |
|
| Back to top |
|
|
csauls
Joined: 27 Mar 2004
Posts: 278
|
| Posted: Sun May 16, 2004 9:39 am Post subject: Mixins |
|
|
If Walter's mixins spec flies, and becomes implemented anytime soon, I daresay that would be the way to have our Singletons done. As it is I'm having to copy-paste the same code into each Singleton class, when we could (now hopefully) just do:
| Code: |
module sinbad.singleton;
template Singleton(alias T)
{
public static T singleton()
{
if (_singleton is null) {
_singleton = new T;
}
return _singleton;
}
private static T _singleton;
}
|
| Code: |
module sinbad.root;
private import sinbad.singleton;
class Root
{
mixin Singleton!(Root);
protected:
this()
{
}
}
|
_________________
Chris Nicholson-Sauls |
|
| Back to top |
|
|
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
| Posted: Sun May 16, 2004 12:07 pm Post subject: |
|
|
| That would be a great feature! Mixins could be used for many of the cases where C/C++ use macros. |
|
| Back to top |
|
|
csauls
Joined: 27 Mar 2004
Posts: 278
|
| Posted: Sun May 16, 2004 12:18 pm Post subject: |
|
|
| larsivi wrote: | | Mixins could be used for many of the cases where C/C++ use macros. |
My thoughts exactly. As soon as I read the mixin spec, I started picturing templates getting used much as #define's are in C++. Only with a little filtering on their parameters. And hopefully not as often. I'd hate to see this turn D into a mixin-jungle the way C++ is a preproc-jungle. But I guess we're going off-topic. 
_________________
Chris Nicholson-Sauls |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Thu May 20, 2004 11:03 am Post subject: |
|
|
| larsivi wrote: | Why the 'static this()'? Just have an if in the singleton getter:
| Code: |
if (_singleton is null) {
_singleton = new Root();
}
|
|
the use of "static this" avoids issues related to thread contention over singleton construction. An entire subculture grew up around this issue within Java <g> |
|
| Back to top |
|
|
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
| Posted: Sun May 30, 2004 2:01 am Post subject: |
|
|
The indentation of the singleton module seems to be messed up in my Vim (on Windows). Edit: This is also the case with the copy in the repository, see web svn.
Also, why do we use 'alias clazz' (corny) instead of T? (Won't argue, just wondering.) |
|
| Back to top |
|
|
csauls
Joined: 27 Mar 2004
Posts: 278
|
| Posted: Thu Jun 17, 2004 2:44 pm Post subject: |
|
|
The indentation is indeed screwy, and its DIDE's fault. No, seriously, it is, honest. I'm switching back to EditPlus for the time being so that should be fixed shortly. I'll also be fixing a curious pseudo-error of mine, the reasoning behind which eludes even me, and I'm the one that typed the darn things...
And I used clazz because A) the parameter is supposed to be a class, so its descriptive, B) I guess its just one of those things I learned from Java.
_________________
Chris Nicholson-Sauls |
|
| Back to top |
|
|
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
| Posted: Sat Jan 29, 2005 10:27 am Post subject: |
|
|
Funny thing; I just noticed that none of the constructors in the OGRE classes inheriting Singleton are protected. Instead all of them are public. I suppose this means that there are uses of these classes where the singleton approach don't fit. The common base for the samples use the EventProcessor constructor directly, even if it derives from Singleton. Well, it's easy to fix. Just switching 'protected' to 'public' in the Singleton mixin
Edit: NOT that easy to fix as the constructor isn't part of the mixin. Well, I'll get by. |
|
| Back to top |
|
|
csauls
Joined: 27 Mar 2004
Posts: 278
|
| Posted: Sat Jan 29, 2005 2:31 pm Post subject: |
|
|
Hmf.. strangeness. Okay, then the "Singletons have protected constructors" policy is bunk.
You know... and you may shoot me for saying this if you wish... but it might be good to scrap the current SVN image and start from scratch. Its not like we have anything significant done. I just think it would be good to start over and better plan the layout of the code, and plus its just been a good long while and we've all changed a little.
Glad to see Sinbad isn't forgotten... I just haven't been able to tend it, but that might change soon (now that I'm employed again). I also was hoping to wait for D 1.0 but that looks further and further away.
_________________
Chris Nicholson-Sauls |
|
| Back to top |
|
|
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
| Posted: Sat Jan 29, 2005 5:09 pm Post subject: |
|
|
| csauls wrote: |
You know... and you may shoot me for saying this if you wish... but it might be good to scrap the current SVN image and start from scratch. Its not like we have anything significant done. I just think it would be good to start over and better plan the layout of the code, and plus its just been a good long while and we've all changed a little.
|
Hmm, that depends quite a lot on the direction we want Sinbad to follow. It's beginning to dawn on me that; either you design everything from scratch (API, functionality, implementation, etc) or you follow through, accepting the design choices made by the OGRE team. The only part that we might be able to filter out for a D redesign is the event system as it somewhat independent of the rest. The rest follow something that looks like a really careful design and messing with it probably destroy everything. It's just to damn big and complex to redesign in any significant way. I would really like to create my own engine from scratch, but it would probably never get off the ground. To have any sort of impact, it HAS to be big and complex and that takes time, which I don't know where to find. If you think it's doable for 2+ and want to try I might consider joining in, otherwise I'll continue to plug away (slowly).
| csauls wrote: |
Glad to see Sinbad isn't forgotten... I just haven't been able to tend it, but that might change soon (now that I'm employed again). I also was hoping to wait for D 1.0 but that looks further and further away. |
Good for you! (The job, that is) I think D is close enough, there has been no significant changes to the language in a long time. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
