Path: news.cs.au.dk!news.net.uni-c.dk!howland.erols.net!europa.netcrusader.net!194.176.220.129!newsfeed.icl.net!colt.net!newspeer.clara.net!news.clara.net!skynet.be!analog.skynet.be!poster!not-for-mail
From: Atle <trollet@skynet.be>
Newsgroups: comp.lang.beta
Subject: Re: OO - General questions, suggestions and ...
Date: Mon, 03 Jul 2000 11:52:58 -0100
Organization: Belgacom Skynet SA/NV
Lines: 68
Message-ID: <39608CAA.51C426D0@skynet.be>
References: <3958ADC9.C4E320B1@skynet.be> <y4yg0przjl0.fsf@odin.mjolner.dk>
NNTP-Posting-Host: dialup177.charleroi.skynet.be
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news0.skynet.be 962617629 32287 195.238.7.177 (3 Jul 2000 09:47:09 GMT)
X-Complaints-To: abuse@skynet.be
NNTP-Posting-Date: 3 Jul 2000 09:47:09 GMT
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
Xref: news.cs.au.dk comp.lang.beta:12510

Flemming Gram Christensen wrote:
> 
> Atle <trollet@skynet.be> writes:
> 
> > ... the inevitable call for help :-) OK, so one of <my kind> can ask
> > more questions than ten of <your kind> 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.
Thanks, that 'deblocked' the situation.
> 
> The suspend solutions is also useable.
This was intended as an experiment, but I programmed myself into a corner, so now some new questions arise ... one of them is how to
tell the outside world that a coroutine has ended.

It had 

	open: (* open the file *);
	close:(* close the file *);
	token: (* SUSPEND with each new token *);

So, the program using it, would call open, read tokens until EOS and then call close.
Somehow, this is not what I had in mind.
I will do the tokenizer like you suggested, because that is absolutely more logical than this :-)

Thanks, Atle