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
