DMD 1.005 release

[BCS]

Walter Bright wrote:
> 
> Yes, in the end, I think that's a more maintainable solution. You'll 
> find your core modules will become much more portable, and you shouldn't 
> need to edit (or even understand) them at all when porting to a new 
> platform.
> 
> If your job is to port the gc to a new XYZ platform, would you find it 
> easier to edit the long and complicated gcx.d, or just copy gclinux.d to 
> gcXYZ.d and restrict your work to just figuring out how to port a few 
> lines of code with (hopefully) well-defined behavior?
> 

And there in lies the primary issue I have with this approach. Say I do 
the above and then a bug is found in the system independent parts of the 
module, now I have to extract the fix from a fixed version and reapply 
it to my version.

I am a strong proponent of the theory that you should never have two 
peaces of /Identical/ code (as in does the exact same thing). It's kinda 
sorta the Extreme Programming model[*] but that's not where I'm coming from.

An example, I am working on a D lexer, it needs to work on 6 type of 
files ASCII and UTF-8/16BE/16LE/32BE/32LE. also to make things easier 
downstream, I have it convert all EOLs to \n. Well rather than write 6 
scanners, I wrote one that was templated on two types (I think) results 
in correct conversions. It is about 30 lines long and the sum total 
difference between the functions is the types on about about 3 lines. 
Now if at some point I find a bug, I fix it in one place and I'm done.

The same sort of thing can apply to other cases.


* I think that is the model but I could be remembering the wrong name