[comp.lang.postscript] Question about Level 2 PostScript 'resources'

ghost@aladdin.com (L. Peter Deutsch) (01/03/91)

I just finished reading through section 3.9 of the new PostScript
Language Reference Manual, which is about 'resources' -- sort of like
an object-oriented extension in which the instances of each class
('category') are loaded dynamically from files as needed, and cached
in memory.  This seems like a pretty cool idea to me, a nice
generalization of the way fonts are handled in environments that have
file systems.  However, I'm puzzled about an apparent interaction
between resource category implementation and the global/local memory
management machinery.  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.  Am I missing something here?

I would appreciate enlightenment on this admittedly obscure topic.

L. Peter Deutsch :: Aladdin Enterprises :: P.O. box 60264, Palo Alto, CA 94306
ghost@aladdin.com ; {uunet,sun,decwrl}!parcplace!aladdin!ghost ; (415)329-0264
	    "Implementation is the sincerest form of flattery."

taft@adobe.com (Ed Taft) (01/06/91)

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