Path: news.cs.au.dk!not-for-mail From: Flemming Gram Christensen Newsgroups: comp.lang.beta Subject: Re: OO - General questions, suggestions and ... Date: 03 Jul 2000 10:47:23 +0200 Organization: University of Aarhus, Department of Computer Science (DAIMI) Lines: 87 Message-ID: References: <3958ADC9.C4E320B1@skynet.be> NNTP-Posting-Host: odin.mjolner.dk X-Trace: xinwen.cs.au.dk 962614049 817116 255.255.255.255 (3 Jul 2000 08:47:29 GMT) X-Complaints-To: news@cs.au.dk NNTP-Posting-Date: 3 Jul 2000 08:47:29 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: news.cs.au.dk comp.lang.beta:12508 Atle writes: > ... the inevitable call for help :-) OK, so one of can ask > more questions than ten of can answer ... that is old > wisdom: Een taabe kan spørge mere, end ti viise kan svare ... :-D) > > But still, I am doing a 'tokenizer' as an excercise. The program > scans the file for atoms, so the pattern file.getAtom determines > what a 'token' looks like. I feel that there are three main object > involved here: > > - Program > - TokenStore > - FileReader > > I have made a working program, but the only part of it I am satisfied with, is TokenStore. > An instance of the TokenStore pattern understands > - storeToken: (* Store a TokenName:, do nothing if token: already in TokenStore: *) > - has: (* see if TokenName: already in TokenStore: *) > - putLine: (* Write out the contents of TokenStore: *) > Hi I would do it like: --program:descriptor-- (# myStore:@tokenStore; (* with storeToken,has,putline operations *); myReader:@tokenReader; (* with read operation *); MyAnalyzer:@Analyzer; f:@file; .... do ...->f.open; MyStore.init; (f[],MyStore[])->myReader.init; (* now reader knows where to read from, and (* where to store tokens *) MyReader.readFile; (* calling storeToken on its store reference *) .... MyStore[]->MyAnalyzer.init; MyAnalyzer.start; #); Eventually you could write 'empty' interfaces for tokenStore, tokenReader, Analyzer, and make subpatterns that implements them. The implementation of each should not need to know the implementation of the other. This way you can use the reader for different stores, etc. Eg. different implementations of reader, can use different notions for tokens. The suspend solutions is also useable. Regards. Flemming. > But now what? > This is where a C-programmer would write a procedure ReadFile, calling TokenStore.StoreToken for each found atom, and be happy if it > works. But I know this is not the way, the beauty of TokenStore and the ugliness of the rest has me convinced. > I am unable to see the 'Object' connection here: Is TokenStore a Partobject in FileReader? > That would work, but ... how about the other way around: TokenStore knows how to get tokens from file? > That is a little more logical ... but still not it. > I don't like this sort of confusion ... but I think I know how it must be, but before I do it that way and upload my 'tokenizer', I > would like to know what you think about it: > I finally found an application for my generators - > > FileReader: is a TokenGenerator: > ------------------------------ > > For each found token, it will SUSPEND with the found token in its EXIT list. > The Program is the main singular object, and contains the TokenGenerator: and the TokenStore: as Partobjects. It will contain a loop > (should it contain a FILE: or not?) calling TokenGenerator and StoreToken until (what? TokenGenrator returns: ___?) > > Is this the way? > -- Flemming Gram Christensen, M.Sc., Software Engineer, Mjølner Informatics ------------------------------------------------------------------------ Mjolner Informatics ApS Phone: +45 70 27 43 43 Science Park Aarhus Fax: +45 70 27 43 44 Gustav Wieds Vej 10 DK-8000 Aarhus C Denmark E-mail: gram@mjolner.dk ------------------------------------------------------------------------