[type_traits] Modularization proposal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Stephen Kelly-2
Andrey Semashev wrote:

>> 1) Why does mplcore exist? Why is its content not in core?
>
> Because it has a distinct set of functionality which may not be needed
> by a Core user.

Pick any two things in core. One of them might be needed by some user of it
while the other is not.

> Merging MPL.Core with Core would make Core heavier and
> add more dependencies to it, which contradicts its incentive.

... or it could consume those dependencies (or at least be in the same repo
and the same modularized release tarball) and really be core.

>> 4) Why is static_assert not part of core? What is the value of it being
>> seprate?
>
> Frankly, I would merge it with Assert or Config, although I did not
> analyze reports to see the consequences. In any case, it's a leaf
> library, so it doesn't add much.

What do you think the term 'leaf' means?

What the separation 'adds' is extra/different/separate things you need to
have/get before you can use a higher-level library.

>
>> 5) What if core actually contained 'core stuff'? What if core contained
>> 'toolchain normalization' (such as static_assert emulation, a
>> BOOST_STATIC_CONSTANT macro, etc) and facilities essential (ie, core) to
>> the rest of boost?
>
> The problem is that the set of "essential facilities" differ from one
> Boost library to another. Some only needs Config, other need stuff
> from Core and Preprocessor, third require MPL, TypeTraits and Utility.

True...

> The solution is to make multiple such fundamental libs, each
> implementing its part of common functionality and having minimal
> dependencies.

Leading to the apparent 'ideal' of one class per library.

An alternative solution would be to group the (small amount of) fundamental
stuff together in one repo/library. That's at least what QtCore does, for
example. It doesn't matter if two classes within it are technically
unrelated. The suggestion is providing a one-stop-shop (download tarball or
repo) for the core stuff which between 60 and 88 of the libraries in boost
use, because it is 'core'.

Then the challenge is balance between keeping it small enough and keeping it
relevant enough (by actually having core stuff in it).

>> 6) What if core was bigger? What if using boost library Foo only required
>> me to download/install boost core and a *small* handful of other
>> *independent* (not interdependent, as most of boost is now) dependencies
>> in order to use it? This trend of creating tens of tiny 1/2/3 file
>> "libraries" and "sublibs" runs/sprints against that kind of scenario.
>
> This would be a step towards monolithic Boost.

No, not really. It would be analysis of what the core stuff is, and then
grouping that core stuff together. A dependency on Boost.Core should not be
a problem and should provide core stuff. Boost.Core should be designed so
that that is true.

[Aside: current boost is not much less monolithic than it was in svn. It's
released/downloadable monolithically]

> What if my library only
> needs BOOST_ASSERT? Do I have to pull half of MPL and TypeTraits along
> in this "bigger core"?

Yes. You as a developer would install boost-core.git or boost-core.tar.gz
and then you would develop mylib, whatever it is.

A user could download/install boost-core.tar.gz and mylib.tar.gz instead of
boost-mplcore.tar.gz, boost-static_assert.tar.gz and boost-assert.tar.gz
before getting to mylib.tar.gz.

Very little depends on only one of these 'low level' libraries.

> As I see it, the problem with the current state is not the amount of
> core libraries but the unnecessary transitive dependencies they
> impose. It's not a problem to download Core and MPL.Core separately,
> as long as these libs don't require much themselves (like Utility or
> TypeTraits, for example).

Similarly, if they don't require much themselves (and if most dependers use
both of them), it's not a problem to combine them.

Thanks,

Steve.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Emil Dotchevski-3
In reply to this post by Andrey Semashev-2
On Wed, Sep 17, 2014 at 6:28 AM, Andrey Semashev <[hidden email]>
wrote:

> On Wed, Sep 17, 2014 at 4:11 PM, Stephen Kelly <[hidden email]> wrote:
> > Andrey Semashev wrote:
> >
> >> I propose to extract common_type.hpp (and its implementation and tests)
> >> into a sublib within type_traits (e.g. type_traits/common_type).
> >
> > Rather than creating tens of tiny 'sublibs' when considering one module
> at a
> > time, all of the small libraries at the 'bottom' of the graph of boost
> > libraries (ie the libraries with very few dependencies and which have
> many
> > dependencies themselves) should be considered together for
> re-organization.
>
> That's subject for a debate.
>

+1


> > You seem to be focusing on small problems which remove a small number of
> > nodes from some dependency graphs in a few cases. There are bigger
> problems
> > which, when fixed, drop tens of nodes in most cases. Those problems are
> the
> > serialization->spirit edge and the range->algorithm edge. I would
> prioritize
> > all this stuff at the 'bottom' of the graph after those big problems in
> > order to get more benefit.
>
> One of the goals of modularization is to eliminate circular
> dependencies. Another is to reduce the amount of dependencies between
> the libraries. I think, I'm working in both directions.
>

Specifically, reducing the number of the libraries should always be
secondary to the drive to reduce dependencies. If there is a part of an
existing library that is logically complete and independently useful, it
should be refactored into a separate component.

> 2) Given the number of dependers of these modules, they are all certainly
> > "core". However, probably only a subset of files within them are depended
> > on. What are those important files and why shouldn't they be moved to
> core?
>
> Extracting MPL.Core was an attempt to identify those "most wanted"
> headers. Merging MPL.Core and Core, I think, is a bad idea for the
> reasons I mentioned above.
>

+1


> > 5) What if core actually contained 'core stuff'? What if core contained
> > 'toolchain normalization' (such as static_assert emulation, a
> > BOOST_STATIC_CONSTANT macro, etc) and facilities essential (ie, core) to
> the
> > rest of boost?
>
> The problem is that the set of "essential facilities" differ from one
> Boost library to another. Some only needs Config, other need stuff
> from Core and Preprocessor, third require MPL, TypeTraits and Utility.
> The solution is to make multiple such fundamental libs, each
> implementing its part of common functionality and having minimal
> dependencies.
>

...so that user code that needs a tiny piece of core doesn't pull in the
kitchen sink.


> > 6) What if core was bigger? What if using boost library Foo only
> required me
> > to download/install boost core and a *small* handful of other
> *independent*
> > (not interdependent, as most of boost is now) dependencies in order to
> use
> > it? This trend of creating tens of tiny 1/2/3 file "libraries" and
> "sublibs"
> > runs/sprints against that kind of scenario.
>
> This would be a step towards monolithic Boost. What if my library only
> needs BOOST_ASSERT? Do I have to pull half of MPL and TypeTraits along
> in this "bigger core"?
>

+1

--
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

John Maddock-3
In reply to this post by Andrey Semashev-2
>>> Hmm, I didn't notice that header. Ok, assuming we don't want to move
>>> this one
>>> header to its own sublib, what if we approach it from the other side.
>>> We can
>>> move all type traits except common_type.hpp and type_traits.hpp to a
>>> sublib
>>> base (i.e. type_traits/base). floating_point_promotion.hpp would be
>>> changed to
>>> not depend on MPL before moving to base.
>>
>> This seems almost ridiculous. If one can choose to not include the headers that incur the dependencies, then one can avoid then when desired. Those that don't care will just include boost/type_traits.hpp.

+1

> The problem is that dependencies (for installation, not compilation)
> will unlikely be tracked on per-header basis, but rather on
> per-library basis.

The point is that currently there is no tracking of dependencies at all,
as I've said before it's all vapour-ware at present, I see no great
benefit in pushing stuff around until there's a definite target to aim at.

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

John Maddock-3
In reply to this post by Peter Dimov-2
>> On Tuesday 16 September 2014 20:06:27 John Maddock wrote:
>> > What happens to boost/type_traits.hpp in this scheme (which depends
>> on > *all* of type_traits)?
>>
>> Hmm, I didn't notice that header. Ok, assuming we don't want to move
>> this one header to its own sublib, what if we approach it from the
>> other side. We can move all type traits except common_type.hpp and
>> type_traits.hpp to a sublib base (i.e. type_traits/base).
>> floating_point_promotion.hpp would be changed to not depend on MPL
>> before moving to base.
>
> How about we just remove the common_type include from type_traits.hpp?

Because it breaks users code?

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12