Re: Performance & import

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-06-11 09:27:01

Vladimir Prus <ghost_at_[hidden]> writes:

>> My inclination is to allow syntaxes for both results, and to do the
>> latter by default, if only to limit the scope of changes to source.
>> Perhaps:
>>
>> import foo/bar ; # bring in rules as bar.baz, etc.
>>
>> import foo.bar ; # bring in rules as foo.bar.baz, etc.
>>
>> ??
>
> I mostly agree to you. I really don't want to write
> "utils.path.parent" all over the place, so the latter syntax should
> be default. Also, I don't think we should compicate the matters now
> and allow another syntax. Why don't we try the latter syntax only
> for some time.

I guess that might be OK.

> BTW, what's the motivation for 
>
> import uitls/path ;
>
> style, as opposed to 
>
> import path ;
>
> Better indication of what layer we're using? 

The motivation is basically the same as for Python packages. Systems
grow. We're going to allow users to write modules with arbitrary
names, and eventually we'll almost certainly want to use the same
module name in two different layers.

> I'm thinking that if string layering is to be enforced, we can allow

string layering?

> import path ; 
>
> but check that it does not grab module from "wrong" level.

I guess I don't understand what you're suggesting.

>> > But anyway: we've got to allow plain imports without directory in
>> > 'project-root.jam' so adding binding of including module to search
>> > paths will still be needed.
>>
>> Sure.
>
> And the same for toolsets:
>
> using gcc ;
>
> must remain the same.

But that, fortunately, is not "import gcc". We're allowed to be smart
and invoke "import tools/xxx" from the implementation of "using xxx."

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com