Larry Wall <[EMAIL PROTECTED]> writes: > On Tue, Jul 12, 2005 at 08:48:41PM +0300, Gaal Yahas wrote: > : I propose to throw away the filesystem coupling, and map from a more > : general name of the bit of code we are requiring to a more general > : description of which instance of it we actually got. Once modules return > : interesting values, it might be useful to keep a copy of that value > : somewhere on the value side of %*INC: or else turn it inside out and > : stipulate that a standard field in the Module object is where you got > : this particular module. > > Yes, that's basically what I was mumbling about in my response. Now just > make sure %*INC is lexically scoped. > > : Probably, %*INC values should be weak references. > > Why should they be weak references? If %*INC is lexically scoped > then its entries represent this lexical scope's *real* references to > modules, and there's no need to weaken them, since it's not functioning > as some kind of cache. As long as this lexical scope sticks around, it > needs the modules it points to. As soon as the lexical scope is destroyed, > it doesn't need them any more. (Counting all closures over this lexical > scope as preserving its needfulness, until all such closures are dead > objects.) > > It's my conjecture that any explicit need for weak references probably > indicates a design failure somewhere. Something like the mis-scoping > of a reference variable, or maybe only something niggly like the > absence of a feature like "is cached" to encapsulate weak semantics. > Or maybe something as major as the lack of robust GC, in the case of > Perl 5...
So long as there's some way of asking the garbage collector for everything in the live set so you can grep through them I'm sure you're right. Because almost everything is extensible at runtime a class is going to need some way of finding all its (and its subclasses) instances so it can update 'em when/if it's definition changes. I'm also trying to think how an object/database mapper could be made to work effectively without being able to keep track of all its managed objects, or would that just be handled through the use of 'is cached'?
