Re: [jamboost] Refactoring progress report

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-14 00:42:40

Ali Azarbayejani wrote:

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

OK, let it be called "core".

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

This approach is OK. I was asking because some of packages in my diargam would 
go in single layer and there are dependencies inside layer, as the result.

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

I see.

> > 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'm not about to argue about exact name, but would like the name to indicate 
that conversion is being done, not that some existing attribute as retrieved. 
E.g. "property.as-minimized-path" to "property.to-minimized-path" are better, 
IMO.

- Volodya