On Tue, 2008-07-15 at 15:26 +0200, Stéphane Ducasse wrote:
> Hi
>
> I would like to get your thoughts on the following:
>
> Following the blog of ramon and his code in sandstoneDB which extends
> dataStream
> as follows:
>
> Here is a typical example:
>
> fileNamed: aName do: aBlock
> | file | file := self fileNamed: aName.
> ^ file
> ifNil: [ nil ]
> ifNotNil: [ [ aBlock value: file ] ensure: [ file close ] ]
>
>
> fileNamed: aString
> "Here is the way to use DataStream and ReferenceStream:
> rr := ReferenceStream fileNamed: 'test.obj'.
> rr nextPut: <your object>.
> rr close.
> better use: fileNamed:do:
> "
>
> | strm |
> strm := self on: (FileStream fileNamed: aString). "will
> be binary"
> strm byteStream setFileTypeToObject.
> "Type and Creator not to be text, so can attach correctly to an
>
> email msg"
> ^ strm
>
>
>
>
> There is similar pattern in FileStream
>
>
> detectFile: aBlock do: anotherBlock
>
> | file |
> file := aBlock value.
> ^ file
> ifNil: [ nil ]
> ifNotNil: [ [anotherBlock value: file] ensure: [file close]]
>
>
>
>
> fileNamed: fileName
> ^ self concreteStream fileNamed: (self fullName: fileName)
>
>
> fileNamed: fileName do: aBlock
> "Avi Bryant says, ''This idiom is quite common in other languages
> that make heavy use of closures
> (i.e. Lisp (with-file 'foo' (f) ...) and Ruby (File.open('foo'){|
> f|...})). It's time Squeak had it, too.''
> Returns the result of aBlock."
>
> ^ self detectFile: [ self fileNamed: fileName ] do: aBlock
>
>
>
> I have a question:
> - would not be better to even wrap the on: into the first block of
> the ensure: message?
What do you mean? Can you give an example?
> - do we have to close a file even if its creation failed?
Is there anything in the above examples that raises this question?
Usually it is the other way round. You can't close a file (that you
don't have) if the creation failed.
I was wondering about the name of the methods. Is a idiom
smthg create
aBlock value: smthg
smthg destroy
not supposed to be called during: ?
Norbert
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
