On Mar 21, 2010, at 20:49 , Marcus Denker wrote:

> 
> On Mar 21, 2010, at 8:40 PM, Adrian Lienhard wrote:
> 
>> On Mar 21, 2010, at 19:50 , Marcus Denker wrote:
>> 
>>> 
>>> Yes... #isInMemory is clearly not needed anymore.
>> 
>> Well... it is needed for the swapping out of classes. If we remove 
>> #isInMemory, we should also remove the whole image segment stub mechanism 
>> because it becomes useless without the isInMemory protection. 
>> 
> 
> 
> But was this ever working? Was this ever *used* the last 10 years? Are 
> actually all cases covered? So are there enough #isInmemory checks to not end 
> up with loading
> everything anyways?
> 
> We already removed the *gently variants for iterating over subclasses, for 
> example. or the "ifPresentAndInMemory" things....

Yes, I did some experiments with it lately and managed to create 4MB images. 
Cases which are not protected are indeed a problem.

>> I would like to keep that working and extract it with the image segments 
>> code into an external package. How to do this cleanly is an interesting 
>> question, though... 
>> 
> 
> I think we should ask the question: Do we intent to *use* this mechanism *at 
> all* the next 5 years?

Probably not. Nevertheless, I think its a nice idea but if it is not properly 
working the chances are small anybody will use.

In any case, the question of how this *could* be factored out in a clean way is 
interesting if we want to further strip and modularize the image. It seems we 
are missing appropriate abstractions to modify from external packages behavior 
like the #isInMemory sends. Overrides are an unsatisfactory solution. So there 
is a limitation to the kind of code can be made external packages.



> 
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
> 
> 
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to