DMD 1.005 release

[Walter Bright]

BCS wrote:
> 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.

If there's a lot of identical code in this approach, then perhaps the 
abstraction layer is drawn in the wrong place. There isn't much in the 
gc version api implementations.

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

Using templates is a great way to write generic code, but it's a 
different approach than using versions.