Working on a library: request for code review

[Xavier Bigand via Digitalmars-d-learn]

Le 12/06/2014 20:35, Xavier Bigand a écrit :
> Le 12/06/2014 20:09, Rene Zwanenburg a écrit :
>> On Thursday, 12 June 2014 at 15:46:12 UTC, Mike wrote:
>>> On Thursday, 12 June 2014 at 00:20:28 UTC, cal wrote:
>>>> Might it be worth stitching things together into a proper image
>>>> processing package?
>>>
>>> Well I started working on TGA because I was disappointed that no image
>>> abstraction is present in Phobos. Go has some imaging APIs and I think
>>> D would benefit from having one too (out of the box).
>>>
>>> Would I work on std.image? Sure.
>>>
>>> Best,
>>> Mike
>>
>> I'm looking over your code ATM but I'd like to reply to this first.
>>
>> IMO it's not a good idea to create something like std.image. The std lib
>> should ideally never have breaking changes, so it's easy to get stuck
>> with a sub optimal API or become increasingly hard to maintain.
>>
>> We have Dub. Better keep the std lib lean and maintainable. If you're
>> looking to create an awesome idiomatic D image library you're probably
>> better of building it on top of derelict-devil or derelict-freeimage,
>> then publish it on code.dlang.org
>>
>> The discoverability of good code.dlang.org projects is still limited.
>> Some kind of rating or like system would be useful, but that's another
>> discussion.
>
> I think it can be a great advantage to have some things like image
> management in phobos, cause often dub projects are big and users don't
> want necessary a complete multimedia library but just small pieces that
> are standard.
> For example a GUI library, will allow image manipulations, but not only,
> and extracting only the image modules can be hard. That the case of our
> DQuick project.
>
> For a project like DQuick, I would be happy to find things like images,
> geometric algebra,environment analysis,... in phobos. This will allow
> use to be focused on other things making an UI framework (Windows,
> events, rendering, resource management,...).
>
> Having such minimalistic APIs would be a great benefit IMO, maybe in
> this case some extending libraries would appear in dub.

I am thinking an other benefit is what you see as a default, the 
assurance of D standard conformances (portability, safety, quality, 
support,...).