From: ptkwt@...1.aracnet.com (Phil Tomson) Date: 2001-10-04T07:46:14+09:00 Subject: [ruby-talk:22034] Re: Marshal won't dump a Proc In article <20011004.063633.2113903881.13076@zipworld.com.au>, HarryO wrote: >In article <1002126975.600438.16806.nullmailer@ev.netlab.jp>, "Yukihiro >Matsumoto" wrote: > > >> Procs, Bindings and Continuations contain references to C stack >> information which is not portable. Methods have references to C >> function. All of above information is not portable. > This seems reasonable, but it also means that I can't use Proc's with dRuby since dRuby uses Marshalling. :-( I was thinking of sending Proc's over to objects running on different machines (using dRuby). > >What I might be able to do is provide two means of constructing the >object, one by attaching a block and the other by passing a string that's >eval-ed into a Proc for run-time use and dumped/restored for persistence. > I'm not sure I totally understand what you are doing, but it seems like you're having the user supply a function to your class (a Proc) that is used to supply a sequence of numbers (am I right?). What if you had a module called UserSupplied (for example) that got included into your class? The user would have to define a function in the UserSupplied module. Something like: #file: UserSupplied.rb module UserSupplied def myUserFunction puts "In myUserFunction" end #user can edit this file to add or change functions in this #namespace. end #file: YourClass.rb class YourClass include UserSupplied def initialize load "UserSupplied.rb" #this would ensure that if the user changes #UserSupplied.rb after the program began to #run that the new or changed functions in #the UserSupplied module would get mixed in. #(at least I think it should work, I haven't #tried it :) end end Would this work for you? I guess the drawback is that your users would have to know Ruby, but even with your other method where they supply a string with Ruby code they would have to know Ruby, so I guess it doesn't matter. Phil