I think that we missing a way to determine to which package some
global belongs to.
When you loading a package it can declare new global, but there is no
reflective mechanisms in system to tell, to which package it belongs.
If we could have that, then clearly, if you serialize the package, you
would want to serialize its globals as well,
and if not, you can just leave a reference to it, which will be
rewired at materialization.

On 17 April 2012 18:20, Eliot Miranda <eliot.miranda@gmail.com> wrote:
>
>
> On Tue, Apr 17, 2012 at 3:50 AM, Mariano Martinez Peck
> <marianopeck@gmail.com> wrote:
>>
>> Hi guys. In Fuel, we need to identity which globals present in Smalltalk
>> globals are NOT classes or traits, because we need to manage them as
>> globals. So far we have a hardcoded list:
>>
>> defaultGlobalSymbols
>>
>> ��� ^ #(#Smalltalk #SourceFiles #Transcript #Undeclared #Display
>> #TextConstants #ActiveWorld #ActiveHand #ActiveEvent #Sensor #Processor
>> #ImageImports #SystemOrganization #World)
>>
>> So...as every hardcoded stuff, this is not nice because as soon as globals
>> change, we need to fix this. So it would be nice if the system (pharo) can
>> provide us this information.
>>
>> What do you think?
>
>
> What I think is that the set of globals depends on usage. �Some time I might
> actually want to serialize the SourceFiles Array, sometimes I might not want
> to. �So this should be configurable, with a sensible default. �Just as when
> one serializes a set of classes, references to classes outside the set are
> not serialized, serializing some subset of global objects in Smalltalk
> should serialize those objects, not references. �So design some convenient
> API that allows one to specify which objects are not globals, and have the
> default be e.g. all global objects in Smalltalk.
>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> best,
> Eliot
>

--
Best regards,
Igor Stasenko.