On Mar 21, 2010, at 9:14 PM, Adrian Lienhard wrote:
>> 
>> 
>> 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.
> 

Nice!

>>> 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.
> 
Yes. But it is clear that Mariano has to come up with a workable perfect 
solution within 3 years anyway ;-) hehehe :-)

> 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.

Hmm... I think I will commit this question as a low-priotiy process to my 
subconciouness... this is a *real* interesting question. Putting code 
*everywhere* makes no sense. (esp. when generalizing to
not just classes, but all objects).

And isn't a class-on-disk nevertheless a class? If I ask the system for all 
classes, why would it omit those that are by chance on Disk? Are those suddenly 
"not classes" anymore?

        Marcus


--
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

Reply via email to