If the method is installed, I would only store a reference (MyClass>>#myMethod). That's what is done on Class, they are stored by reference:
String streamContents: [:strm | Array storeOn: strm] -> 'Array' Otherwise, if the method is not installed, I would not store a trailer pointing to some source somewhere indeed, but why not a trailer encoding compressed temp vars or direct source... Anyway, is the trailer a relevant point of comparison ? Nicolas 2010/1/4 Igor Stasenko <siguc...@gmail.com>: > 2010/1/4 Henrik Johansen <henrik.s.johan...@veloxit.no>: >> >> On Jan 4, 2010, at 2:45 57AM, Levente Uzonyi wrote: >> >>> On Wed, 30 Dec 2009, Stéphane Ducasse wrote: >>> >>>> BIG THANKS igor!!! >>>> >>>> 11127 >>>> ----- >>>> >>>> - Issue 1690: New Method Trailer part 7 (cs 9) >>> >>> There are still some issues. Some methods (for example TPureBehavior >> >>> #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). >>> These should be removed asap (I had to make some surgery with #become: to >>> compile the new version.) >>> >>> >>> Levente >> >> CompiledMethod>>storeOn: also needs to be updated, >> >> (Compiler evaluate: aCompiledMethod storeString) does not reconstruct the >> original trailer. >> > > The only way how you should be allowed to reconstruct a compiled > method from string, is compilation, otherwise you risking crashing the > system. > But compilation _always_ creating a new artifact - a compiled method , > and picking an appropriate trailer for it. > > The way, how CompiledMethod>>storeOn: does, seems an abuse, as to me, > because i won't bet on safety of keeping a methods in such format, > even for existing images. > For instance, you could store a method , then condense changes, and > then if you attempt to restore it, you will end up with having a > sourcePointer pointing to > invalid .changes file location. > > So, i rather prefer seeing this method implemented like following: > > CompiledMethod>>storeOn: aStream > ^ self shoulNotBeImplemented > >> Caught by ArrayTest >> testComplexIsSelfEvaluating, of all places :) >> >> Cheers, >> Henry >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
