Just out of curiosity: Why are PUSecurity linked to too many other objects? Is there a bug leaking memory?
Lukas
On Thursday, 17 November 2011, Martin Dias <tinchodias@gmail.com> wrote:
> Hello!
> On Thu, Nov 17, 2011 at 1:56 AM, Yanni Chiu <yanni@rogers.com> wrote:
>>
>> An earlier version of Fuel did not having the substitution feature. So, I had custom mapping code to pre-process the structures before passing to Fuel for serialization, and to post-process the deserialized structures. The main purpose of the code was to nil out the PUSecurity objects, because they were linked to too many other Pier objects.
>>
>> I'm now eliminating the custom mapping code by using Fuel substitution. The PRFile object was handled by saving the file contents in an instance variable of the mapping object. I've eliminated the custom mapping object. Now, how should the file contents be saved/restored, using the substitution feature?
>>
>> I'm thinking of substituting a proxy object, which somehow "becomes" a PRFile after deserialization.
>
> you can implement :
> YourPRFileProxy >> fuelAfterMaterialization
> � � self become: self proxiedPRFile
> �
> Anyway, in next version would be nice to provide a faster way of doing this, without become.
>>
>> Any other suggestions?
>>
>>
>
>
--
Lukas Renggli
www.lukas-renggli.ch