Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker.mit.edu!apple!olivea!decwrl!adobe!taft
From: taft@adobe.com (Ed Taft)
Newsgroups: comp.lang.postscript
Subject: Re: Question about Level 2 PostScript 'resources'
Message-ID: <9660@adobe.UUCP>
Date: 6 Jan 91 03:27:05 GMT
References: <39.UUL1.3#5127@aladdin.com>
Sender: news@adobe.COM
Reply-To: taft@adobe.COM (Ed Taft)
Organization: Adobe Systems Incorporated, Mountain View
Lines: 27

In article <39.UUL1.3#5127@aladdin.com> ghost@aladdin.com (L. Peter Deutsch) writes:
>This seems like a pretty cool idea to me...

Thanks for the nice compliment. You wouldn't believe how long it took to
work out a complete design based on this seemingly simple idea.

>The dictionary that defines a resource
>category is stored in global memory.  The manual says that each
>category must manage global and local instances separately.  However,
>objects in global memory can't reference objects in local memory.
>This means that the resource category dictionary, which would
>otherwise be the obvious place to keep track of the instances, can't
>be used to keep track of local instances.  Instead, it appears that
>there must be some kind of parallel structure in local memory for
>each resource category.

You are correct, and I believe this is precisely how we have implemented it.
Doubtless you would like an explanation for this seemingly arbitrary
restriction. If the restriction were not imposed, there could be different
implementations for global and local instances of a category. But the global
and local instances interact in certain ways; for example, a local instance
obscures a global instance having the same name. Thus, the two category
implementations would need to be coupled together somehow; it is unlikely
that two independent implementations could coexist. The semantics seemed
unnecessarily complicated and insufficiently useful, so we simply outlawed
this case.
Ed Taft      taft@adobe.com      ...decwrl!adobe!taft