On 04.01.2011 7:30, Guilherme Vieira wrote:
I may sound daring or even foolish proposing this, but here goes
nothing.. one of the things that bothers me about software
development is that people always tell you not to reinvent the
wheel, but the libraries available are generally not fine-grained
enough, so you end up either using overkill solutions to ridiculously
small problems or actually reinventing the wheel.
For example, what do you do if you want to create a window just for
use with OpenGL in a cross-platform way? You have to write different
versions of the window creation procedure for the different systems
you're targeting. Or you could use SDL, but if you really just want
the window that's a waste. Right?
For that particular case GLUT may fit just fine. Or GLAux.
At times like this I wish people would really break their code in
smaller parts in a way you could really just pick what you want from
it.
Dependencies are the main problem here I think. E.g. library A fit the
bill but uses it's own matrices lib B and quaternions lib C and so on.
And what's worse quite another useful library D has it's own set of
reinvented wheels. In such cases you can tear down library in small
pieces but then you'd have to resolve dependencies.
So I thought, since D has such a compact community and the codebase
is still small, maybe you would like to attack the "problem" (dunno
if many will agree with me this is a problem, but then I'd like to
know what they do in the case I described) together.
I'd like to propose a community-written, community-reviewed
hierarchy of modules anybody could (and should :)) contribute to.
Necessities would be factored and layered before entering the actual
hierarchy, though.
Sounds a lot like std lib. Maybe an incubator project for Phobos?
(was discussed sometime ago) Also check scrapple on Dsource.
For example, right now I really wanted a cross-platform way of using
OpenGL. AFAIK, OpenGL usage is normalized across many systems and
only its initialization is platform-depedent (to begin with, there's
WGL, GLX and AGL; plus, you have very different ways of creating
windows in those systems, so you need to do a lot of work to really
use OpenGL in a cross-platform manner).
I would then engage into writing what's needed and, when done, I
would send it for the community to review. The modules would be
fragmented, trying not to compromise its usability in any possible
use-case.
The core notion here is that D libraries could be the community's,
not the author's. I wonder if merging people's efforts can be a good
idea. I mean, you would avoid reinventing the wheel, you would avoid
having many libraries doing the same thing with different
interfaces, essentially making two user-libraries, each using one of
the first ones, incompatible when in a perfect world they really
shouldn't be, etc..
The only problem with it : people still can't invent the best way to do
something, plus the matter of taste.
Two libraries no problem, two big frameworks - bound to be incompatible
and overkill for most uses.
So, what do you think?
* Is it viable?
* Would it be useful?
Yup ! :)
* Improvements?
May be require the modules in this hierarchy to reduce cross-dependency
unless absolutely needed?
What I would like is "D2 reconnaissance project" i.e. maintain a list
of all actively developed D2 projects.
--
Dmitry Olshansky
