dsource.org - forums

dsource.org

Open Source Development for
the D Programming Language

FAQ

Memberlist

Usergroups

Profile

Utility package ideas

Forum Index -> Derelict

View previous topic :: View next topic

Author

Message

JJR

Joined: 22 Feb 2004
Posts: 1104

Posted: Wed Feb 23, 2005 3:42 am Post subject:

aldacron wrote:

Now that utility package is looking more attractive than ever. I really would like to eliminate the redundant lib loading/unloading code, and implement some custom exceptions to distinguish between the failure to load a library (library missing/not found) and the failure to load a symbol from a library (library corrupt/incompatible version).

I would like to see such a utility package as well. I kind of find the name Derelict*_Load distractingly out of place in my code. I guess the name is chosen to stand out, but it doesn't follow D convention. If it were part of a singleton class such that Derelict.GL.load() were used, it would look more appropriate.

If you can get an exception system working with Derelict, I'm sure it will improve the feel overall. I still wish we could get static module ctors up and running... it's so seemless... unfortunately, it's also a lost cause as I understand it. *sigh*

- John R.

aldacron

Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

Posted: Wed Feb 23, 2005 5:44 am Post subject:

JJR wrote:

Hate to disappoint you, but the Derelict*_Load syntax isn't going away anytime soon. I'm a C-type at heart Smile

I just don't see the need to create any classes, static or otherwise, for direct library bindings. I could just rename everything to 'load' and one could do the derelict.opengl.gl.load() thing, but that's more typing! The utility package, btw, doesn't change the external loading interface, but the internal one (i.e. global getProc() and loadLib() functions).

Quote:

I still wish we could get static module ctors up and running... it's so seemless... unfortunately, it's also a lost cause as I understand it.

In the beginning, when I first wanted to do that, I didn't think it through. Loading in the module ctor would mean that the lib is always loaded even when you don't want it to be. Imagine creating pluggable renderers with OpenGL and D3D implementations. You don't need both libraries loaded at once. If you want to allow the user to switch between implementations on the fly, you'll want to load/unload at will. So even if the situation changes with module ctors and thrown exceptions, I don't intend to implement any such thing for Derelict anymore.

JJR

Joined: 22 Feb 2004
Posts: 1104

Posted: Wed Feb 23, 2005 6:41 am Post subject:

It's more typing but:

Code:

with (derelict.opengl.gl)
{
load_GL();
load_GLU();
}

kinda looks nice. Okay, it's more typing... The method becomes more useful for libraries like SDL, which have many different modules.

NOTE: Isn't opengl.gl redundant? Can't it just be derelict.opengl? And then glu can be put in the same directory. It can still be compiled separately if necessary as its own library. But it is part of opengl.

Ah, but you have good answers and reasons for both points. It's better to keep to the Derelict design goals. Concerning the static modules, I hadn't thought of the need for the pluggable aspect of the whole thing. Good point.

My original opinion about the Derelict*_Load name still stands, though, but such naming methods are merely a matter of taste and have no effect on total library design. So thanks for bearing with me on this one. You've got a great system going. I was just nit-picking and not very well at that. Smile

- John R.

Display posts from previous:

	Forum Index -> Derelict	All times are GMT - 6 Hours
Page 1 of 1

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