On Tue, Jan 4, 2011 at 11:13 AM, spir <denis.s...@gmail.com> wrote: > On Tue, 4 Jan 2011 02:30:24 -0200 > Guilherme Vieira <n2.nitro...@gmail.com> wrote: > > > 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. > > I guess this is a dream generations of programmers, language designers and > computer scientist have run after. Say, Lego programming. Bulding bricks > which are _really_ autonomous. > Maybe there is a flaw in the implicite reasoning behind that vision: as a > client, one wants the (library) building blocks they use to be autonomous, > right; but at a higher-level the software one is designing is precisely > using other software, thus creating a system of dependancies... which makes > this new piece of code unusable in an autonomous manner by yet another > client who would enjoy reusing it as a brick. The same applies to the > (library) bricks: they have to use other building blocks which prevent them > to be autonomous. > > This is how I see the point. And it gets even more unavoidable because of > generality. For a brick to have any chance to meet one client's needs it > must be as general/abstract as possible. This means for instance abstract > away issues of OS idiosyncrasies, actual types, sizes and loads of other > annoying aspects, think at how write*, map, or file opening work. To do > this, using yet another bunch of tools is often necessary. The more a brick > gets general and thus useful, the more chances it has _not_ to be > autonomous. I guess. > This, to the point that if Phobos (2) would be rewritten from scratch using > everywhere D2's newer style (more general/abstract, as I see it), most of > its modules would import a load of other modules such as algorithm, > contracts, functional, range, possibly type*, traits, variant; which > themselves import... > > I don't logically there can be a solution. I would like to try to define a > minimal subset D lib functionality, say the standard toolkit. (I have one > for my personal, a dozen elements systematically imported, and most commonly > actually used, in every of my modules.) Then, make this a kind of > auto-import (à la python) for user code, except if other wise stated; and > see if it's enough, overkill, whatever. > Then, struggle to make (other) lib modules depend on these toolkit > elements, and only and them, as much as possible. (Even when it's not the > best design/code solution.) Could such an approach work? > > > Denis > -- -- -- -- -- -- -- > vit esse estrany ☣ > > spir.wikidot.com > > Yes, I don't see how could each module not depend on each other, but that's not the point. It would be a hierarchy, after all; there would have to be dependencies. But I don't particularly care if a C++ library depends on Boost, for example. Boost is behemoth, but it is well-modularized (you can really pick just a pretty small subset of it) and, more importantly, it's so widely accepted it's almost a standard library. So who cares?
On Tue, Jan 4, 2011 at 9:06 AM, Dmitry Olshansky <dmitry.o...@gmail.com>wrote: > Sounds a lot like std lib. Maybe an incubator project for Phobos? > (was discussed sometime ago) Also check scrapple on Dsource. > I don't think it could get into Phobos. I think of relatively bigger things, too, such as cross-platform mouse, keyboard and gamepad input library done right to be the definitive way of doing that on D. That just doesn't seem fit for a true standard library, does it? 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. > I see GLUT solves the problem for OpenGL, but then we get to the granularity point: the input library I told you above also needs a window. To make it depend on GLUT would be stupid. And then we get back to the wheel reinvention problem. The only problem with it : people still can't invent the best way to do > something, plus the matter of taste. > The "best way" of doing something is always a subjective matter. But, as usual, one can define rules that, when fully respected, result in something that can be tagged at least as "pretty good". Make those rules community-reviewed and you normalize people's needs. I'm pretty sure much of D was decided this way. Also, if you are really thorough in deciding how to break the pieces of the system, then maybe people won't be too bothered if it's a bit off their tastes. -- Atenciosamente / Sincerely, Guilherme ("n2liquid") Vieira