Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!usc!ucla-cs!rutgers!att!cbnewsc!jwd From: jwd@cbnewsc.ATT.COM (joseph.w.davison) Newsgroups: comp.object Subject: Re: Pre-computing objects Message-ID: <4158@cbnewsc.ATT.COM> Date: 27 Oct 89 21:05:36 GMT References: Reply-To: jwd@ihlts.ATT.COM (joseph.w.davison,312 979 4920) Distribution: usa Organization: AT&T Bell Laboratories Lines: 50 In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >I> >> Some time ago a discussion arose in comp.lang.c++ about reading objects in >> from, say, a disk file. There were several answers, but none that seemed >> all that great, so I hope to start a discussion of the subject here. >> ... >In C++, the only type-safe, compile-time method for supporting this that I >have found involves having parent objects knowing about their children's >structure so that if they get such an object on their initializer function, >they know what to do with it. There is a basic translation mechanism that >must be invoked somewhere and, no matter what I have tried to do, I have only >succeeded in moving the problem from one layer of objects to another. > >Anyone have any ideas? Well, ignoring the issue about methods being stored with the objects, which is hardly ignorable, I'll address the simpler problem of reading a text file, recognizing the next "object" and creating one of "them". ThiI encountered the problem in Smalltalk while trying to process some computer generated files of "messages" that had a variety of formats. I had created a class Message with various subclasses, one for each different message format. The Message objects had methods to allow users to "interpret" or, more generally, to interact with them. The problem was to create objects of the proper type as the file was read. I intend/intended to do this same job in C++, and have done a similar job as you suggest -- make the parent's constructor know about the child's structure. That just doesn't seem right. The way I wish I could do it is with OOYACC -- Like Yacc, but designed to work in an OO system. Basically, I want yylex() and yyparse() and their relatives to be member functions. I want to be able to tell when a parser is successful/fails -- perhaps a static data member of the parent could be used for this info. Then the parent class needs only to know the names of its child classes. Each class provides a constructor that takes a stream as input and applies its own yyparse() to it. If the parse is successful, the constructor can do its job, and the static data member is set to SUCCESS. If the parse fails, the static data member is set to FAILURE and the constructor does nothing else. The parent constructor tries to create instances of each child, in some order, until one succeeds, or it fails -- and does whatever constructors do when they fail. This idea at least limits the amount of information the parent needs about the child. Of course, OOYACC does not exist... -- Joe Davison jwd@ihlts.att.com