From: Robert Klemme Date: 2009-03-02T23:30:54+09:00 Subject: Re: Marshal.load does not create new instances? --000325575702d2fdbc046423ae4f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/2/28 Ian Trudel : >> Ian, I'm not sure I understand what you want. AFAIK Marshal only works >> if you have the same class definitions on both sides. Why is this a >> problem for you? > > This is actually how I use Marshal. It works fine if I have only one > version in one given Ruby program. The problem resides in loading > different files which may contain one version or another of the given > class definition. There are sometimes additional (or less) instance > variables and methods, different implementation of certain methods, etc. > depending on the version of the class. Mmm. collision problems, > Capitain! > > My initial hope was on defining the main class in such way to delegate > to other classes (named and implemented according to its version). In my > twisted mind, I had imagined something that I could set the delegator to > a certain class before loading the data, just like any other proxy, and > then use it; or at least before using methods or accessors. > >> Ian, you should be aware of one thing: class definitions are not >> serialized - no programming language that I know does this. =A0And there >> are probably good reasons (security, efficiency probably). > > Understandably. :) > >> 1. use OpenStruct >> 2. use Hash >> 3. change your class Data to store attributes in a single Hash only > > Once again a good idea! Unfortunately, it is not just about data but > also about class and instance methods and their specific implementation. > Would it mean that I could mixin the instance of OStruct with my > specific version of a class (as a module) at that point? > > >> You can use tricks as 7stud suggested although I feel wary about this. >> =A0I would probably choose a different solution based on the >> requirements (which are not fully clear to me). =A0If you just need >> changing sets of attributes then these options might work: > > I have data files generated by different softwares. These files are > generated according to a given class but the implementation (accessors, > methods, etc.) are slightly different according to the software. They > share the same name, basic functionalities and data though they have > differences according to their version. I would like to be able to load > and use them within my Ruby program, any or many of these generated > files at the same time without collision. Requirement was that I do not > have access to the original source of the softwares and I do have to > reimplement and test each version all by myself. > > We should perhaps see the problem as if it was extreme: let's imagine > that we have multiple programs which have each a class Data but is > completely different (no similar instance variables nor methods, nothing > in common at all). No access to those programs and yet have to load all > the files within a single Ruby program. What one would do? > > Thanks for your help, guys! As Brian has hinted, you can use instance_variable_get etc. to access variable values. You can even make it a bit more convenient (see attached file for examples). Kind regards robert --=20 remember.guy do |as, often| as.you_can - without end --000325575702d2fdbc046423ae4f Content-Type: application/octet-stream; name="t.rb" Content-Disposition: attachment; filename="t.rb" Content-Transfer-Encoding: base64 X-Attachment-Id: f_frt91tyd0 IyEvdXNyL2Jpbi9lbnYgcnVieQoKZGVmIGNyZWF0ZV9hY2Nlc3NvcnMoaW5zdGFuY2UpCiAgY2wg PSBjbGFzczw8aW5zdGFuY2U7c2VsZjtlbmQKICBpbnN0YW5jZS5pbnN0YW5jZV92YXJpYWJsZXMu ZWFjaCBkbyB8aXZ8CiAgICBjbC5zZW5kIDphdHRyX2FjY2Vzc29yLCBpdlsvXEFAKC4qKVx6Lywx XS50b19zeW0KICBlbmQKICBpbnN0YW5jZQplbmQKCm1vZHVsZSBQc2V1ZG9IYXNoCgogIGRlZiBr ZXlzCiAgICBAaW5zdGFuY2VfdmFyaWFibGVzLm1hcCB7fGl2fCBpdlsxLi4tMV19CiAgZW5kCgog IGRlZiB2YWx1ZXMKICAgIEBpbnN0YW5jZV92YXJpYWJsZXMubWFwIHt8aXZ8IGluc3RhbmNlX3Zh cmlhYmxlX2dldCBpdn0KICBlbmQKCiAgZGVmIFtdKGtleSkKICAgIGluc3RhbmNlX3ZhcmlhYmxl X2dldCAiQCN7a2V5fSIKICBlbmQKCiAgZGVmIFtdPShrZXksdmFsKQogICAgaW5zdGFuY2VfdmFy aWFibGVfc2V0ICJAI3trZXl9IiwgdmFsCiAgZW5kCmVuZAoKaWYgdGVzdCA/ciwgIm0iCiAgY2xh c3MgVGVzdERhdGE7IGVuZAogIG9iaiA9IEZpbGUub3BlbigibSIsInJiIikge3xpb3wgTWFyc2hh bC5sb2FkIGlvfSBhbmQgRmlsZS51bmxpbmsgIm0iCiAgcCBvYmouY2xhc3MubWV0aG9kcy5ncmVw KC9mb28vaSkuc29ydAogIGl2ID0gb2JqLmluc3RhbmNlX3ZhcmlhYmxlcwogIHAgaXYKICBpdi5l YWNoIHt8dnwgcCBbdiwgb2JqLmluc3RhbmNlX3ZhcmlhYmxlX2dldCh2KV19CgogIGNyZWF0ZV9h Y2Nlc3NvcnMgb2JqCiAgcCBvYmouZm9vCgogIG9iai5leHRlbmQgUHNldWRvSGFzaAoKICBwIG9i alsiZm9vIl0sIG9ials6Zm9vXQplbHNlCiAgY2xhc3MgVGVzdERhdGEKICAgIGF0dHJfYWNjZXNz b3IgOmZvbwogIGVuZAoKICBvYmogPSBUZXN0RGF0YS5uZXcKICBvYmouZm9vID0gVGltZS5ub3cK ICBGaWxlLm9wZW4oIm0iLCJ3YiIpIHt8aW98IE1hcnNoYWwuZHVtcChvYmosaW8pfQplbmQK --000325575702d2fdbc046423ae4f--