DIP11: Automatic downloading of libraries

[Jacob Carlborg]

On 2011-06-20 14: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 ;)

I personally think that just because Phobos uses these features will not 
make them less "hackish".

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

D2 has many new cool feature and I would love to use some of them, but 
every time I try they don't work. I'm tried of using a language that's 
not ready. I still think Tango is a better library and I like it better 
than Phobos. Although Phobos is doing a great job of filling in the 
feature gaps in every new release.

-- 
/Jacob Carlborg