On 17 April 2012 18:52, Eliot Miranda <[email protected]> wrote:
>
>
> On Tue, Apr 17, 2012 at 10:11 AM, Igor Stasenko <[email protected]> wrote:
>>
>> 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.
>
>
> +1.  Some construct that defines a module, analogous to a class definition?

+1. I haven't had a chance to look yet, but it's possible Michael van
der Gulik's SecureSqueak does this already, or has taken steps towards
doing it:

* http://securesqueak.blogspot.co.uk/2011/05/now-where-was-i.html
* http://gulik.pbworks.com/
* http://gulik.pbworks.com/SecureSqueak

Michael's said he'd need to cut a new release if I (we) wanted to make
use of it.

frank

>> On 17 April 2012 18:20, Eliot Miranda <[email protected]> wrote:
>> >
>> >
>> > On Tue, Apr 17, 2012 at 3:50 AM, Mariano Martinez Peck
>> > <[email protected]> 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.
>>
>
>
>
> --
> best,
> Eliot
>

Reply via email to