Subject: Re: [boost] [castor] Interest in Logic Paradigm for C++ ?
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-05-03 19:05:37
----- Original Message -----
From: "Roshan" <roshan_naik_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, May 03, 2010 11:20 PM
Subject: Re: [boost] [castor] Interest in Logic Paradigm for C++ ?
>
> On Sun, 02 May 2010 20:40:39 -0600, OvermindDL1 <overminddl1_at_[hidden]>
> wrote:
>
>> However, I notice a *lot* of overlap with Boost.Phoenix, it kind of
>> seems like a continuation layer on top of Boost.Phoenix, and it
>> probably could in fact be implement as a layer of Boost.Phoenix
>> (Boost.Phoenix is made up of layers of functionality, and a logic
>> layer makes sense). Boost.Phoenix is a lazy evaluation framework for
>> C++. When it is finished being ported to Boost.Proto for
>> Boost.Phoenix 3,
>
>
>> I think a Caster-style Logic layer would make a lot
>> of sense, and would allow it to blend far more easily into the rest of
>> boost while getting all the functionality of Boost.Phoenix (including
>> the calling style fixes that Boost.Phoenix uses, val/ref's and such),
>> along with pure lazy *type* inference too (which Caster does not do at
>> all, not a major limitation, but one that could cause more code to be
>> created at times then necessary), which would solve the whole
>> list/vector thing the tutorial talks about (along with supporting any
>> generic container transparently).
>>
>> Have you thought about this?
>
> Nope! I have restrained from introducing any cross library dependencies in
> an effort to keep it a standalone library. I am very keen on ensuring
> Castor continues to be distributable & usable as a standalone library even
> if included into Boost.
>
> However your suggestion interests me. From what I read, it seems that it
> might be possible to "peel off" just the necessary amount of Phoenix
> without dragging in all of Phoenix or rest of Boost. This sounds appealing
> to me since I want to ensure :
>
> (Benefits to end users + Benefits of code reduction in Castor's
> internals) > disadvantages of depending on another library (Phoenix)
>
> Often these secondary libraries are too big (mcuh bigger than all of
> Castor) and in turn depend on other (Boost) libraries. Castor 1.0 is a
> really small library (under 5k LOC).
> The simple lambda support in Castor 1.0 totals to about 300 lines of
> code... compare that to relying on the "all powerful" boost.lambda which
> is about 14k LOC. Wasn't worth it.
Hi,
this is no the first time some one want to introduce a library in Boost but don't want to use nothing of Boost; even if the abstraction already exist in Boost.
Whether a library I use is about 1KLOC or 100KLOC it is not important to me, if the service the library provides is what I need.
What kind of users do you want to preserv with a standalone library that will not use your library if it depends on Boost?
Best,
Vicente