Package globals sometimes duplicated?

Blair,

I got my code/view generator working well enough to try it under D5, and ran
into a problem.  The failure turned out to be caused by an inability to find
a particular "global variable" in the system dictionary.  After some poking,
I realized that there were 8 of these "globals" that were causing trouble,
and they turned out to be the ones that are held in (collection) instance
variables by their peers.  A simple explanation would be that I had
inadvertently copied the objects in my 4.01 image, but, the counts there are
correct.  On loading the package into D5, the objects referenced by their
peers were duplicated, or so it seemed.

File in D5GlobalBug below, and evaluate this in D4:

  GlobalX := D5GlobalBug new.
  GlobalY := D5GlobalBug new peer:GlobalX; yourself.

Accept the new global variabless and add them to a package with D5GlobalBug.
Save it and load it into D5.

Having done that, I think you'll find that D5 has three instances of
D5GlobalBug where D4 has only two.  Can you reproduce it?

Have a good one,

Bill



"Filed out from Dolphin Smalltalk 2000 release 4.01"!

Object subclass: #D5GlobalBug
 instanceVariableNames: 'peer'
 classVariableNames: ''
 poolDictionaries: ''
 classInstanceVariableNames: ''!
D5GlobalBug comment: ''!

D5GlobalBug guid: (GUID fromString:
'{F9F15E20-1F53-11D6-8596-0000B49D2CF2}')!

!D5GlobalBug categoriesForClass!Unclassified! !
!D5GlobalBug methodsFor!

peer
 "Private - Answer the value of the receiver's ''peer'' instance variable."

 ^peer!

peer: anObject
 "Private - Set the value of the receiver's ''peer'' instance variable to
the argument, anObject."

 peer := anObject! !
!D5GlobalBug categoriesFor: #peer!accessing!private! !
!D5GlobalBug categoriesFor: #peer:!accessing!private! !


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill

You wrote in message news:[hidden email]...
>
> I got my code/view generator working well enough to try it under D5, and
ran
> into a problem.  The failure turned out to be caused by an inability to
find
> a particular "global variable" in the system dictionary.  After some
poking,
> I realized that there were 8 of these "globals" that were causing trouble,
> and they turned out to be the ones that are held in (collection) instance
> variables by their peers.  A simple explanation would be that I had
> inadvertently copied the objects in my 4.01 image, but, the counts there
are
> correct.  On loading the package into D5, the objects referenced by their
> peers were duplicated, or so it seemed.
>
> File in D5GlobalBug below, and evaluate this in D4:
>   GlobalX := D5GlobalBug new.
>   GlobalY := D5GlobalBug new peer:GlobalX; yourself.
> ...[snip]...

This will behave in exactly the same way in D4 (at least it will when you
reload the package into it). The second global has an instance variable that
points at the value of the first global at the time the expression is
evaluated. It is not a permanent reference to the current value of the
global, since it is not a reference to the variable binding. Since the
globals in a package are filed out independently, they use separate
instances of the STB binary filer, and so there is no shared scope to enable
it to recognise and reconstruct the original shared reference. As I say,
this is the same in D4 (try it). Ironically it may have worked correctly in
D3, since that binary filed the entire package.

I'll record it as an issue, though, as perhaps something can be done about
it in a future release.

Regards

Blair

Blair,

> This will behave in exactly the same way in D4 (at least it will when you
> reload the package into it).

I was wondering about that - the package is relatively new.


> The second global has an instance variable that
> points at the value of the first global at the time the expression is
> evaluated. It is not a permanent reference to the current value of the
> global, since it is not a reference to the variable binding.

True, but, as long as the object is mutated in place vs. a new value
assigned to the variable, then it should be ok - right??? :)  Actually, that
very caveat of "mutate/don't replace" is one mark against what I'm doing; it
also makes them harder to facade across a network.  Back to a registry of
named objects =:0


> Since the
> globals in a package are filed out independently, they use separate
> instances of the STB binary filer, and so there is no shared scope to
enable
> it to recognise and reconstruct the original shared reference.

That beats some kind of problem in the binary filer - not that I was
expecting that; it's worked too well for too long.


> As I say,
> this is the same in D4 (try it). Ironically it may have worked correctly
in
> D3, since that binary filed the entire package.
>
> I'll record it as an issue, though, as perhaps something can be done about
> it in a future release.

Could you simply file out the collection of globals vs. filing them out
separately?  Easier said than doine of course, and  to be useufl, it would
require a patch to D4.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
>...
> Could you simply file out the collection of globals vs. filing them out
> separately?  Easier said than doine of course, and  to be useufl, it would
> require a patch to D4.

Yes, but the reason for not doing so is that filing them independently
provides some limited isolation against changes made by multiple users when
one is using a traditional file & line-based SCCS, i.e. user A and user B
can both modify the package, even modify the globals, as long as they don't
both modify the same global. I think this is probably less important for
globals than it is for view resources. Theoretically if the
resources/globals were not binary filed, but filed in some text form, one
could actually merge changes together, but I have my doubts as to whether
would actually work that well in practice. As an aside the reason the binary
filed objects are written to a single line is to avoid a typical line based
SCCS thinking that it can merge clashing changes.

Regards

Blair