storeOn: and literal limits

Does anything exist to handle uses of #storeOn: that bump into the literal limit? E.g. that splits the offending constructor method into several methods? Thanks.

Le 13/06/2015 16:06, Sean P. DeNigris a écrit :
> Does anything exist to handle uses of #storeOn: that bump into the literal
> limit? E.g. that splits the offending constructor method into several
> methods? Thanks.

There is some code in SmaCC to handle that.

Thierry

Thierry Goubier wrote

There is some code in SmaCC to handle that.

Would it make sense to extract?

Le 14/06/2015 06:20, Sean P. DeNigris a écrit :
> Thierry Goubier wrote
>> There is some code in SmaCC to handle that.
>
> Would it make sense to extract?

I'd try if it works for you first :)

Code is there:

https://github.com/ThierryGoubier/SmaCC/blob/d5371fbf3298fcf8a0053d5c122db76b08b0b7ca/SmaCC-Development.package/SmaCCSmalltalkCodeGenerator.class/instance/splitTree..st

https://github.com/ThierryGoubier/SmaCC/blob/90257788f495cc8bb3900f64115cca8272a13c06/SmaCC-Development.package/SmaCCSmalltalkCodeGenerator.class/instance/splitSpecificRewriter.st

https://github.com/ThierryGoubier/SmaCC/blob/90257788f495cc8bb3900f64115cca8272a13c06/SmaCC-Development.package/SmaCCSmalltalkCodeGenerator.class/instance/splitTree.toLimit..st

Thierry

storeOn: is old because it will not handle cycles and other.
So I would simply use Ston.

Stef

Le 14/6/15 06:20, Sean P. DeNigris a écrit :

stepharo wrote

storeOn: is old because it will not handle cycles and other.
So I would simply use Ston.

I agree. I ran into two problems right away - internal references are not maintained and it's easy to hit the literal array limit. However, my use case is saving data in Pharo and loading it into Amber, and right now amber-ston is not in a usable state. So, #storeOn: has the unique advantage of saving as Smalltalk source code, and therefore requiring no external library support. So it's useful in simple cases/models where one won't hit those limits