DIP11: Automatic downloading of libraries

[Jacob Carlborg]

On 2011-06-20 14:49, Dmitry Olshansky wrote:
> On 20.06.2011 16:35, Dmitry Olshansky wrote:
>> On 20.06.2011 15:35, Jacob Carlborg wrote:
>>> On 2011-06-20 10:59, Dmitry Olshansky wrote:
>>>> On 20.06.2011 12:25, Jacob Carlborg wrote:
>>>>> On 2011-06-19 22:28, Dmitry Olshansky wrote:
>>>>>
>>>>>> Why having name as run-time parameter? I'd expect more like (given
>>>>>> there
>>>>>> is Target struct or class):
>>>>>> //somewhere at top
>>>>>> Target cool_lib, ...;
>>>>>>
>>>>>> then:
>>>>>> with(cool_lib) {
>>>>>> flags = "-L-lz";
>>>>>> }
>>>>>>
>>>>>> I'd even expect special types like Executable, Library and so on.
>>>>>
>>>>> The user shouldn't have to create the necessary object. If it does,
>>>>> how would the tool get it then?
>>>>>
>>>> If we settle on effectively evaluating orbspec like this:
>>>> //first module
>>>> module orb_orange;
>>>> mixin(import ("orange.orbspec"));
>>>> //
>>>>
>>>> // builder entry point
>>>> void main()
>>>> {
>>>> foreach(member; __traits(allMembers, orb_orange))
>>>> {
>>>> static if(typeof(member) == Target){
>>>> //do necessary actions, sort out priority and construct a worklist
>>>> }
>>>> else //static if (...) //...could be others I mentioned
>>>> {
>>>> }
>>>> }
>>>> //all the work goes there
>>>> }
>>>>
>>>> Should be straightforward? Alternatively with local imports we can pack
>>>> it in a struct instead of separate module, though errors in script
>>>> would
>>>> be harder to report (but at least static constructors would be
>>>> controlled!). More adequatly would be, of course, to pump it to dmd
>>>> from
>>>> stdin...
>>>
>>> I had no idea that you could do that. It seems somewhat complicated
>>> and like a hack. Also note that Orbit is currently written in D1,
>>> which doesn't have __traits.
>>>
>>
>> Well, everything about compile-time introspection could be labeled
>> like a hack. In fact I just seen the aforementioned "hack" on a much
>> grander scale being used in upcoming std module, see std.benchmarking:
>> https://github.com/D-Programming-Language/phobos/pull/85/files#L1R577
>> And personally hacks should look ugly or they are just features or at
>> best shortcuts ;)
>>
>> Personal things aside I still suggest you to switch it to D2. I can
>> understand if Phobos is just not up to snuff for you yet (btw cute
>> curl wrapper is coming in a matter of days). But other then that...
>> just look at all these candies ( opDispatch anyone? ) :)
>> And even if porting is a piece of work, I suspect there a lot of
>> people out there that would love to help this project.
>> (given the lofty goal that config would be written in D, and not Ruby)
>>
> Just looked through the source , it seems like you are doing a lot of
> work that's already been done in Phobos, so it might be worth doing a
> port to D2. Some simple wrappers might be needed, but ultimately:

First I have to say that these simple models are no reason to port to 
D2. Second, here are a couple of other reasons:

* These modules (at least some of them) are quite old, pieces of some of 
them originate back from 2007 (before D2)

* These modules also started out as common API for Phobos and Tango 
functions

* Some of these modules also contains specific functions and names for 
easing Java and C++ porting

Overall I like the API of the modules, some functions are aliases for 
Tango/Phobos functions with names I like better and some are just 
wrappers with a new API.

> util.traits --> std.traits

As far as I can see, most of these functions don't exist in std.traits.

> core.array --> std.array + std.algorithm

When I work with arrays I want to work with arrays not some other kind 
of type like a range. I do understand the theoretical idea about having 
containers and algorithm separated but in practice I've never needed it.

> io.path --> std.file & std.path

Some of these exist in std.file and some don't.

> orgb.util.OptinoParser --> std.getopt

This is a wrapper for the Tango argument parse, because I like this API 
better.

> util.singleton should probably be pulled into Phobos, but a thread safe
> shared version.

Yes, but it isn't in Phobos yet.

-- 
/Jacob Carlborg