Hi Hans, Sorry for the late reply.
On Sun, Nov 25, 2018 at 9:30 PM Hans-Martin <pharo-...@fam-mosner.de> wrote: > I found a related problem which indicates that the depreciation of > StandardFileStream in favor of File is incomplete and probably premature: > When a ZipArchive is written, in 7.0 it uses > (File named: aFileName) > writeStreamDo: [...] > In 6.1, it uses > StandardFileStream > forceNewFileNamed: aFileName > do: [...] > Well, the equivalent of this is: f := File named: aFileName. f exists ifTrue: [ f delete ]. f writeStreamDo: [...]. or f := File named: aFileName. f writeStreamDo: [ :stream | stream truncate. ... ]. This is, I reckon, slightly more verbose. On the other side I personally think that "forceNewFileNamed:" is not so useful nor general, maybe for scripting purposes. I think that libraries (as Zip does here for example) should use that with care, since silently overriding a file can be considered nasty :). Besides, taking a Pharo5 image, users of forceNewFileNamed: and forceNewFileNamed:do: are few, mostly tests. And several of the users do override a file silently (and dangerously IMHO) since the do not make it explicit to the user :/. Take for example in pharo5 MIMEDocument >> saveToFile: anAbsolutePathString FileStream forceNewFileNamed: anAbsolutePathString do: [ :str | str binary. str nextPutAll: (self contents) ]. or Fuel's FLSqueakPlatform >> fileNamed: aFilename writeStreamDo: aBlock ^ FileStream forceNewFileNamed: aFilename do: [ :stream | stream binary. aBlock value: stream ] which override the file but the method name does not indicate it. What if the file being overwritten had important data? which is a small but significant difference leading to corrupted zip > archives when overwriting existing files. File does not have equivalent > protocol to #forceNewFileNamed... so it is pretty likely that there are > more > bugs creeping there. Upon a cursory inspection I see that for example > FLFileStreamStrategy will suffer from the same problem when writing to > existing files. > > Is there any documentation on the reasoning of depreciating > StandardFileStream and who is working on this? I'm really new to pharo > development... Submitting "patches" without knowing the original design > rationale seems not very productive. > I've made part of the effort myself, Sven did a bit part too, and many other people whose names aren't coming out of the top of my head (sorry!). Part of the migration guide is here: https://pharoweekly.wordpress.com/2018/03/19/new-files-in-pharo-migration-guide-how-tos-and-examples/ Paver wrote another one that I cannot find right now. There are many emails around discussing the rationale behind this. But in a couple of words the reason was cleaning up. We had for example the concerns of data encoding and buffering repeated between sockets and file management. And also this was using subclasses, which tend to explode with combinations. We refactored this to use a decorator schema which is far more composable and modular, and lets us reuse cross cutting concerns between memory streams, file streams, sockets, etc. Guille
