On Tue, 4 Jan 2011 02:30:24 -0200
Guilherme Vieira <[email protected]> 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

Reply via email to