Re: [jamboost] Refactoring progress report

From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-05-13 10:45:52

Vladimir Prus wrote:
>
> > > o Layers (tools, build, core)
> >
> > A coarse layering of the 55 current .jam files results in the
> > following three conceptually and structurally useful layers. Note,
> > however, that refactoring will result in creating, deleting, and
> > renaming modules. Some current modules contain material that
> > crosses layers and needs to be separated somehow.
> 
> Some time ago I've drawn a package diagram for V2 (after Ali posted his
> version). I attach it just in case. Looks like basically, they layers are the
> same as proposed now, except that my one is more detailed.

Thanks for posting it. I don't think I've seen it before.

> 
> > - core ----------------------------------------------------------
> 
> Just a naming issue: "core" sounds like "the most important part" for me. In
> fact, it's just a set of utilities. But I may be wrong with english.
> 
> > The "core" layer is a library of bootstrap and core "BBv2 language"
> > constructs and utilities.
> 
> Yes, you give different meaning to "core".

Core means the "center" or "innermost part", like an apple core, like
a seed, or "kernel". It is the part from which the rest of the fruit
grows. So it's only the "most important part" by virtue of everything
else depending upon it. You can't have anything else in the BBv2 system
without "module" and "class" etc. I think "core" is entirely
appropriate
for the low-level concepts because it is the part from which the rest of
the system grows and the part that everything else depends upon.

Other appropriate English terms for that layer would be "substrate",
"foundation", "root", "seed", "kernel" but these are long names or
have other common overloaded meanings in programming.

Main Entry: 1core 
1 : a central and often foundational part usually distinct
from the enveloping part by a difference in nature <core
of the city>
...
2 a : a basic, essential, or enduring part (as of an
individual, a class, or an entity) <the staff had a core of
experts> <the core of her beliefs> b : the essential
meaning : GIST <the core of the argument> c : the inmost
or most intimate part <honest to the core>

Main Entry: ker·nel
1 chiefly dialect : a fruit seed
2 : the inner softer part of a seed, fruit stone, or nut
3 : a whole seed of a cereal <a kernel of corn>
4 : a central or essential part : GERM <like many stereotypes... this
one too contains some kernels of truth -- S. M. Lyman>

> I hope you don't mean a layer can't use modules from the same layer? It's not
> clear from the above.

You're right, and I have to be careful with terminology because
normally individual "modules" within a "layer" may NOT use each other.
Technically, each of these three layers contains a single conceptual
module that contains all the files listed. Within each conceptual
module there is further modularity and layering among the files and
modules associated therewith.

To to be absolutely pedantic

----------------------------------------------------------------------
Tools Layer

+-----------------------------------------------------+
| tools Module |
| |
| +---------+ +---------+ +---------+ |
| | gcc | | msvc | | doxygen | |
| | Module | | Module | | Module | ... |
| +---------+ +---------+ +---------+ |
+-----------------------------------------------------+

----------------------------------------------------------------------
Build Layer

+-----------------------------------------------------+
| build Module |
| |
| ? TBD ? |
| |
+-----------------------------------------------------+

----------------------------------------------------------------------
Core Layer

+-----------------------------------------------------+
| core Module |
| |
| ? TBD ? |
| |
+-----------------------------------------------------+

----------------------------------------------------------------------

The relationships of files and BB "modules" inside of these top-level
conceptual modules is yet to be fully determined.

> > - The introduction of class "property-set" at some point in the
> > development seems to have created some confusion with terminology in
> > earlier-written code, but it seems as though it serves two necessary
> > purposes: (1) provide a single object for manipulating what would
> > otherwise be a list and (2) caching results of certain operations
> > for performance reasons. Volodya, perhaps you can confirm that
> > these are the reasons for its existence?
> 
> Yes. (2) was the primary reason. (1) is a reason too --- property-set is much
> easier to work with that bare list, and this gives additional optimization
> possibilities, as well.

Ok, thanks.

> > - Throughout these three modules and BBv2 in general there is much
> > inconsistency in terminology and naming. The Dynamic Type Checking
> > proposal above will allow us to write clearer code. Some
> > refactoring will re-group functions in a more meaningful way and
> > re-name them. For example, to convert a property-list to a
> > property-path you call "property.as-path", but to do the opposite,
> > you call "feature.split"; these functions should be in the same
> > module and named in a way that expresses their complementary nature.
> 
> They are not complimentaty!
> 
> [ feature.split [ property.as-path $(p) ] ] != $(p)
> 
> "as-path" produces as compact representation of property set as possible. For
> example, if you have "debug" and "<optimization>off" in property set, then
> only "debug" will show up in "path", because it already contains the second
> property. This means that if you decide to rename 'as-path' you must be
> carefull about the name.

Sorry, I missed that. You're right they are not complimentary, but
even more reason to re-name...should be something like
"minimized-path".

I think others have responded to the other points.
--Ali