struct environment

[Daniel Berlin]

On Friday, September 6, 2002, at 03:41  PM, Daniel Jacobowitz wrote:

> On Fri, Sep 06, 2002 at 03:34:34PM -0400, Daniel Berlin wrote:
>>
>>
>>> one which might not even be necessary (see below).
>>>
>>>>> And there's another, even more important reason: the global
>>>>> environment (and, in the future, namespaces).  The global
>>>>> environment spans multiple files, uses lazy evaluation
>>>>> (i.e. partial_symbols), and there's even minimal_symbols to
>>>>> shoehorn in there somehow.  So it's going to need its own special
>>>>> implementation (which will be much more complicated than the
>>>>> implementations for blocks).
>>>
>>>> This is why I don't like the environment == list-of-symbols thing.
>>>> An environment may HAVE a list of symbols, but it is not its list of
>>>> symbols.  You shouldn't grow the list of symbols in the global
>>>> environment when a new file is added.  Instead you should associate
>>>> a new list of symbols with it.
>>
>> This makes lookup dependent on two things, instead of one (number of
>> files, and number of names, vs number of names).
>> Bad idea when you can avoid it.
>> If you want to know what blocks go with which files, than store *that*
>> information.
>> Removal is *not* the common case.
>
> Well, what I had in mind when I wrote that was the same sort of thing
> you originally described - with a cached mapping of symbols -> blocks.
> I do need to sit down and think about how namespaces interact here
> however... gets a little peculiar.
>
>
>> Note that this wasn't the first time someone wanted to do this.  HP 
>> has a
>> whole "FAT_FREE_PSYMTABS" thing in WDB.
>
> Yeah.  Killing psymtabs in general would be nice but that's tabled
> behind stub methods (which I am slowing quashing).
>
> What's the current status of the location expression stuff, by the
> way?

I've been too busy with law school and interviews (2nd year law 
students have interviews for summer jobs in late august and early 
september. Absurd, no?) to work on it.
I did make sure Peter Sofa and Jim Blandy know this, and that if they 
want it done anytime soon, to work on it themselves.
The changes Jim requested probably wouldn't take more than a day or two 
to implement, i just don't have that day or two right now.

>
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>