<div class="gmail_quote">On Tue, Jan 4, 2011 at 11:13 AM, spir <span dir="ltr"><<a href="mailto:denis.spir@gmail.com">denis.spir@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, 4 Jan 2011 02:30:24 -0200<br>
Guilherme Vieira <<a href="mailto:n2.nitrogen@gmail.com">n2.nitrogen@gmail.com</a>> wrote:<br>
<br>
> At times like this I wish people would really break their code in smaller<br>
> parts in a way you could really just pick what you want from it.<br>
<br>
</div>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.<br>
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.<br>

<br>
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.<br>

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...<br>

<br>
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.<br>

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?<br>
<br>
<br>
Denis<br>
-- -- -- -- -- -- --<br>
vit esse estrany ☣<br>
<font color="#888888"><br>
<a href="http://spir.wikidot.com" target="_blank">spir.wikidot.com</a><br>
<br>
</font></blockquote></div><br>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?<br>
<br>On Tue, Jan 4, 2011 at 9:06 AM, Dmitry Olshansky <span dir="ltr"><<a href="mailto:dmitry.olsh@gmail.com">dmitry.olsh@gmail.com</a>></span> wrote:<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
Sounds a lot like std lib. Maybe an incubator project for Phobos?<br>
(was discussed sometime ago) Also check scrapple on Dsource.<br clear="all"></blockquote><br>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?<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote"><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
 For example, what do you do if you want to create a window just for<br>

 use with OpenGL in a cross-platform way? You have to write different<br>

 versions of the window creation procedure for the different systems<br>

 you're targeting. Or you could use SDL, but if you really just want<br>

 the window that's a waste. Right?<br>
</blockquote>

<br>

For that particular case GLUT may fit just fine. Or GLAux.<br></blockquote><br>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.<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">The only problem with it : people still can't invent the best way to do something, plus the matter of taste.<br>
</blockquote><br>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.<br>
<br>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.<br><br>-- <br>Atenciosamente / Sincerely,<br>Guilherme ("n2liquid") Vieira<br>