- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec new release :)

by Camillo Bruni

On 2013-11-13, at 22:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I will write and send a proposal to the list. Good idea. ... and put it in the documentation repository, I thought of gathering the documentation there, centralized, transparent open for contributions from everybody.

Nov. 13, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by Chris Muller

These are really excellent arguments, Nicolas. Good discussion. On Wed, Nov 13, 2013 at 3:32 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Chris, > I have to completely disagree. > The idea of breaking a complex object into simpler parts is not just > theories and extremism. > Assigning several roles to an object is sometimes convenient for a start, > but generally does scale very badly. > It's a collective experience driven by pragmatic considerations in > developping in all sort of languages. > And it's my own experience too. > > A file is like the container, the stream is about reading/writing the > contents. > I think I remember the confusion was made at the beginning in st-80, because > it was simple enough at that time. > So it's rather an historical slag, not something that was added later for > this special case. > And it is something that should have been revised, because when we added > pipes, sockets or other external streams, that ruined the idea of confusing > the two things into a not well delimited blob without clear > responsibilities. > Though we kept the original implementation and started to distort the > package by adding faked polymorphism like name ^'john doe'. > > Clearly, I need no stream on its contents to rename a file, query its > permissions, or delete it, so why bother with internal states of a stream if > I'm interested in handling the file? > If I am interested about the contents, I don't need to ever know about the > path of the file nor its name, or shall I change a $A read from it into a $B > if the file is named 'turnAllAinB'? > > Where exactly are we going to need this encapsulated blob which pretend to > be both a file and a stream? I would be happy to show that a rewrite is both > simple and good looking at end application sites. > Of course, inside the lava of multi year hacked stream hierarchy, it might > be a bit less obvious to disentangle the spaghetti. > Hence more radical solutions: table rase and complete rewrite. > > > > > > 2013/11/13 Chris Muller <asqueaker(a)gmail.com> >> >> On Wed, Nov 13, 2013 at 1:17 PM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > Exactly, every specialized stream has its specialized API and/or >> > specialized >> > implementation. >> > File streams don't even have a name, because they need not to. >> > You can browse XTFileReadStream and XTFileWriteStream, you won't find >> > such >> > thing. >> > The file has a name, the stream does not need any. >> > Before adding anything to a stream, ask first, why am i going to need >> > this? >> >> I agree with what Frank said, but not your suggestion that: >> >> > File streams don't even have a name, because they need not to. >> > If it really need it, the application certainly can retrieve the name >> > from a higher level object (a >> > FIleReference, FileDirectory or whatever). >> >> because doing that means the FileStream is no longer >> fully-encapsulated. And now for the same method to support a >> non-FileStream stream, what will be passed as the new FileReference >> argument? nil? So the code went from stream-delegation to >> case-logic. >> >> This is why organic growth happened in the original Stream hierarchy >> -- because it was "needed", not random. Not strict, yes, but not >> "random" either. >> >> One final thing to consider about selector "uniformity" is how it can >> negate the ability to effectively trace code (via senders and >> implementors). Wow, how many senders of #next...? >> >> Stream-composition is cool, though, and I understand that to be a >> benefit of the stricter API. >> >> >> >> > 2013/11/13 Frank Shearar <frank.shearar(a)gmail.com> >> >> >> >> On 13 November 2013 16:48, Chris Muller <asqueaker(a)gmail.com> wrote: >> >> > I know nothing about Xtreams but, IMO, this obsession with sterility >> >> > borders on mental illness. >> >> > >> >> > "All sort of un-needed complexity?" That's overstating it a bit, >> >> > don't you think? >> >> > >> >> > So you must really feel stressed that ALL Object's, in fact, have a >> >> > #name, huh? I admit this seems to push the limits but... >> >> > >> >> > what's the point of having any kind of different streams at all then? >> >> > It's the _differences_ between them that makes composing them useful. >> >> > Compression, encryption, filtering, sockets, files, circular, etc. >> >> > You think you'll be able to do all that and get away with all of them >> >> > having exactly the same API? >> >> >> >> They don't have the same API. And they shouldn't. And that's Nicolas' >> >> whole point. A Stream does not have a name (nor should it - what's the >> >> name of the compressed output of an audio stream from your >> >> microphone?). A FileStream can extend this API, and that's fine. But >> >> keep that out of the Stream API. >> >> >> >> So Nicolas is arguing that _difference_ should be reflected in the >> >> API. File streams have names, but generic streams do not. >> >> >> >> As it happens, Xtreams takes a very disciplined approach to this. Some >> >> streams have positions, and so you can go back. Some can't. This is >> >> reflected in the API. This is good. >> >> >> >> > IMHO working around that, passing extra objects around, sounds more >> >> > stressful than letting a stream on a _file_ know its filename.. >> >> >> >> Mu. Streams have no names. File streams have names. >> >> >> >> frank >> >> >> >> >> If it really need it, the application certainly can retrieve the >> >> >> name >> >> >> from a higher level object (a FIleReference, FileDirectory or >> >> >> whatever). >> >> > >> >> > How does that solution allow uniformity in stream-using code? >> >> > >> >> > On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier >> >> > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >> Yes, a Wrapper would provide the legacy API. >> >> >> >> >> >> And yes, the name of a stream should better not be part of the API. >> >> >> Most stream don't have a name, and adding such API adds all sort of >> >> >> un-needed complexity. >> >> >> It's an internal detail that can eventually help for reporting error >> >> >> if >> >> >> accessible, but nothing more. >> >> >> >> >> >> If it really need it, the application certainly can retrieve the >> >> >> name >> >> >> from a >> >> >> higher level object (a FIleReference, FileDirectory or whatever). >> >> >> >> >> >> >> >> >> 2013/11/13 Chris Muller <asqueaker(a)gmail.com> >> >> >>> >> >> >>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier >> >> >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >>> > It's just a matter of selecting a strategy. I've proposed two: >> >> >>> > A) create a wrapper class for legacy Stream compatibility >> >> >>> > selectors >> >> >>> > B) create extensions for Legacy Stream compatibility selectors >> >> >>> > My preference goes to A) >> >> >>> >> >> >>> By wrappers you mean the Xtreams are the innards doing the work and >> >> >>> the wrappers providing the legacy API? >> >> >>> >> >> >>> This would be a great way to test Xtreams. >> >> >>> >> >> >>> > The legacy support MUST be minimal (next nextPut: nextPutAll: >> >> >>> > peek >> >> >>> > upTo: >> >> >>> > ...), otherwise we will import all the cruft in Xtream and would >> >> >>> > go >> >> >>> > back >> >> >>> > to >> >> >>> > our starting point... >> >> >>> > Once the minimal support written (a few hours should be enough), >> >> >>> > we >> >> >>> > should >> >> >>> > gradually switch each every legacy Stream usage -> Xtream. >> >> >>> > >> >> >>> > An area which require more work is those Streams that have mixed >> >> >>> > conventions >> >> >>> > (one portion is interpreted as text, another as binary). >> >> >>> > In theory that's easy, we just have two streams and they both >> >> >>> > wrap >> >> >>> > on a >> >> >>> > low >> >> >>> > level binary stream, but that means we have to be very cautious >> >> >>> > with >> >> >>> > buffers >> >> >>> > and caches. >> >> >>> > >> >> >>> > Another area of work is usage of ugly selectors like name (we try >> >> >>> > to >> >> >>> > access >> >> >>> > the file name from the Stream API, arghh). Those usages are bad >> >> >>> > and >> >> >>> > require >> >> >>> > a rewrite. >> >> >>> >> >> >>> Are you saying a FileStream knowing its #name or #filename is bad? >> >> >>> >> >> >> >> >> > >> >> >> > >> >

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by Norbert Hartl

> Am 13.11.2013 um 19:22 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > C- because I'm funny My bet would go on this option :) Norbert

Nov. 13, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by Nicolas Cellier

Chris, I have to completely disagree. The idea of breaking a complex object into simpler parts is not just theories and extremism. Assigning several roles to an object is sometimes convenient for a start, but generally does scale very badly. It's a collective experience driven by pragmatic considerations in developping in all sort of languages. And it's my own experience too. A file is like the container, the stream is about reading/writing the contents. I think I remember the confusion was made at the beginning in st-80, because it was simple enough at that time. So it's rather an historical slag, not something that was added later for this special case. And it is something that should have been revised, because when we added pipes, sockets or other external streams, that ruined the idea of confusing the two things into a not well delimited blob without clear responsibilities. Though we kept the original implementation and started to distort the package by adding faked polymorphism like name ^'john doe'. Clearly, I need no stream on its contents to rename a file, query its permissions, or delete it, so why bother with internal states of a stream if I'm interested in handling the file? If I am interested about the contents, I don't need to ever know about the path of the file nor its name, or shall I change a $A read from it into a $B if the file is named 'turnAllAinB'? Where exactly are we going to need this encapsulated blob which pretend to be both a file and a stream? I would be happy to show that a rewrite is both simple and good looking at end application sites. Of course, inside the lava of multi year hacked stream hierarchy, it might be a bit less obvious to disentangle the spaghetti. Hence more radical solutions: table rase and complete rewrite. 2013/11/13 Chris Muller <asqueaker(a)gmail.com> > On Wed, Nov 13, 2013 at 1:17 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Exactly, every specialized stream has its specialized API and/or > specialized > > implementation. > > File streams don't even have a name, because they need not to. > > You can browse XTFileReadStream and XTFileWriteStream, you won't find > such > > thing. > > The file has a name, the stream does not need any. > > Before adding anything to a stream, ask first, why am i going to need > this? > > I agree with what Frank said, but not your suggestion that: > > > File streams don't even have a name, because they need not to. > > If it really need it, the application certainly can retrieve the name > from a higher level object (a > > FIleReference, FileDirectory or whatever). > > because doing that means the FileStream is no longer > fully-encapsulated. And now for the same method to support a > non-FileStream stream, what will be passed as the new FileReference > argument? nil? So the code went from stream-delegation to > case-logic. > > This is why organic growth happened in the original Stream hierarchy > -- because it was "needed", not random. Not strict, yes, but not > "random" either. > > One final thing to consider about selector "uniformity" is how it can > negate the ability to effectively trace code (via senders and > implementors). Wow, how many senders of #next...? > > Stream-composition is cool, though, and I understand that to be a > benefit of the stricter API. > > > > > 2013/11/13 Frank Shearar <frank.shearar(a)gmail.com> > >> > >> On 13 November 2013 16:48, Chris Muller <asqueaker(a)gmail.com> wrote: > >> > I know nothing about Xtreams but, IMO, this obsession with sterility > >> > borders on mental illness. > >> > > >> > "All sort of un-needed complexity?" That's overstating it a bit, > >> > don't you think? > >> > > >> > So you must really feel stressed that ALL Object's, in fact, have a > >> > #name, huh? I admit this seems to push the limits but... > >> > > >> > what's the point of having any kind of different streams at all then? > >> > It's the _differences_ between them that makes composing them useful. > >> > Compression, encryption, filtering, sockets, files, circular, etc. > >> > You think you'll be able to do all that and get away with all of them > >> > having exactly the same API? > >> > >> They don't have the same API. And they shouldn't. And that's Nicolas' > >> whole point. A Stream does not have a name (nor should it - what's the > >> name of the compressed output of an audio stream from your > >> microphone?). A FileStream can extend this API, and that's fine. But > >> keep that out of the Stream API. > >> > >> So Nicolas is arguing that _difference_ should be reflected in the > >> API. File streams have names, but generic streams do not. > >> > >> As it happens, Xtreams takes a very disciplined approach to this. Some > >> streams have positions, and so you can go back. Some can't. This is > >> reflected in the API. This is good. > >> > >> > IMHO working around that, passing extra objects around, sounds more > >> > stressful than letting a stream on a _file_ know its filename.. > >> > >> Mu. Streams have no names. File streams have names. > >> > >> frank > >> > >> >> If it really need it, the application certainly can retrieve the name > >> >> from a higher level object (a FIleReference, FileDirectory or > whatever). > >> > > >> > How does that solution allow uniformity in stream-using code? > >> > > >> > On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier > >> > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >> Yes, a Wrapper would provide the legacy API. > >> >> > >> >> And yes, the name of a stream should better not be part of the API. > >> >> Most stream don't have a name, and adding such API adds all sort of > >> >> un-needed complexity. > >> >> It's an internal detail that can eventually help for reporting error > if > >> >> accessible, but nothing more. > >> >> > >> >> If it really need it, the application certainly can retrieve the name > >> >> from a > >> >> higher level object (a FIleReference, FileDirectory or whatever). > >> >> > >> >> > >> >> 2013/11/13 Chris Muller <asqueaker(a)gmail.com> > >> >>> > >> >>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier > >> >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >>> > It's just a matter of selecting a strategy. I've proposed two: > >> >>> > A) create a wrapper class for legacy Stream compatibility > selectors > >> >>> > B) create extensions for Legacy Stream compatibility selectors > >> >>> > My preference goes to A) > >> >>> > >> >>> By wrappers you mean the Xtreams are the innards doing the work and > >> >>> the wrappers providing the legacy API? > >> >>> > >> >>> This would be a great way to test Xtreams. > >> >>> > >> >>> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek > >> >>> > upTo: > >> >>> > ...), otherwise we will import all the cruft in Xtream and would > go > >> >>> > back > >> >>> > to > >> >>> > our starting point... > >> >>> > Once the minimal support written (a few hours should be enough), > we > >> >>> > should > >> >>> > gradually switch each every legacy Stream usage -> Xtream. > >> >>> > > >> >>> > An area which require more work is those Streams that have mixed > >> >>> > conventions > >> >>> > (one portion is interpreted as text, another as binary). > >> >>> > In theory that's easy, we just have two streams and they both wrap > >> >>> > on a > >> >>> > low > >> >>> > level binary stream, but that means we have to be very cautious > with > >> >>> > buffers > >> >>> > and caches. > >> >>> > > >> >>> > Another area of work is usage of ugly selectors like name (we try > to > >> >>> > access > >> >>> > the file name from the Stream API, arghh). Those usages are bad > and > >> >>> > require > >> >>> > a rewrite. > >> >>> > >> >>> Are you saying a FileStream knowing its #name or #filename is bad? > >> >>> > >> >> > >> > > >> > > > >

Nov. 13, 2013

Re: [Pharo-dev] Instrumenting field accesses with Opal?

by StÃ©phane Ducasse

>>> Hi! >>> >>> Is there a way to get notified when fields are accessed? >>> That would be awesome >> >> You can use the current reflectivity prototype. It's on RMoD CI: https://ci.inria.fr/rmod/job/Reflectivity/ >> It should look like something like that: >> >> YourClass methods do: [ :method | >> method ast >> forAllNodes: [ :node | node isVariable and: [ node isInstance ] ] >> putAfter: [ RFMetalink expression: 'Transcript crShow: ''iv accessed''' ]; >> installWrapper ]. > > In the end we should be able to just use the Slot MOP ;) so cool :)

Nov. 13, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by StÃ©phane Ducasse

thanks for this discussion it is interesting. I like small api fully implemented vs large and bogus ones Stef On Nov 13, 2013, at 6:47 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > ---------- Forwarded message ---------- > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: 2013/11/13 > Subject: Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic > > The long answer is simple: the more responsibility you put in Stream, the more complexity you get. > The first complexity that I'm speaking of is non-uniformity and random implementation (or un-implementation) of a set of features. > I mean some streams in the huge hierarchy implement only half of the contract, but hey, what was the contract exactly? > Ah, yes, there were no contract, just hacks left here and there randomly and concurrently in a big hierarchy. > I add a new subclass, but don't implement all the features, there are too many of them, and I don't know them all.. > I add a new feature, but don't implement it in all the classes, there are too many of them, and I don't know them all. > This procedure invariably ends up with a blob of un-maintanable code, were two stream would not even agree on upToEnd behavior - I think you remember it :) > > If the goal is to replicate all the accumulated responsibilities of Squeak Streams, but with a clarified contract, I think this is a dead end: too much cruft to support, too many features, too many undefined or not well defined behaviors to be clarified. > > Xtreams takes the opposite path: concentrate on constructing a common, simple and uniform API, concerning streams, just basic stream methods. > Some specialized streams then implement some specialized behavior, and you can compose them (by wrapping) when you need the specific API. > This way, you ain't got to implement/maintain feature A into a few dozen of classes. > And your brand new SpecialFeatureBStream only has to implement a few well known behaviours and your Special Feature B. > > The short answer is even more simple : a stream does not have a name, like a collection does not have a name, because we ain't gonna need it. > If we really need a name, then we'll create a XTNamedReadStream and a XTNamedWriteStream responding to #name, but I doubt we'll do. > > > 2013/11/13 Chris Muller <ma.chris.m(a)gmail.com> > On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Yes, a Wrapper would provide the legacy API. > > And yes, the name of a stream should better not be part of the API. > Most stream don't have a name, and adding such API adds all sort of un-needed complexity. > It's an internal detail that can eventually help for reporting error if accessible, but nothing more. > > > I know nothing about Xtreams but, IMO, this obsession with sterility borders on mental illness. > > "All sort of un-needed complexity?" That's overstating it a bit, don't you think? > > So you must really feel stressed that ALL Object's, in fact, have a #name, huh? I admit this seems to push the limits but... > > what's the point of having any kind of different streams at all then? It's the _differences_ between them that makes composing them useful. Compression, encryption, filtering, sockets, files, circular, etc. You think you'll be able to do all that and get away with all of them having exactly the same API? > > IMHO working around that, passing extra objects around, sounds more stressful than letting a stream on a _file_ know its filename.. > > If it really need it, the application certainly can retrieve the name from a higher level object (a FIleReference, FileDirectory or whatever). > > How does that solution allow uniformity in stream-using code? > > > > > > > > 2013/11/13 Chris Muller <asqueaker(a)gmail.com> > On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > It's just a matter of selecting a strategy. I've proposed two: > > A) create a wrapper class for legacy Stream compatibility selectors > > B) create extensions for Legacy Stream compatibility selectors > > My preference goes to A) > > By wrappers you mean the Xtreams are the innards doing the work and > the wrappers providing the legacy API? > > This would be a great way to test Xtreams. > > > The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo: > > ...), otherwise we will import all the cruft in Xtream and would go back to > > our starting point... > > Once the minimal support written (a few hours should be enough), we should > > gradually switch each every legacy Stream usage -> Xtream. > > > > An area which require more work is those Streams that have mixed conventions > > (one portion is interpreted as text, another as binary). > > In theory that's easy, we just have two streams and they both wrap on a low > > level binary stream, but that means we have to be very cautious with buffers > > and caches. > > > > Another area of work is usage of ugly selectors like name (we try to access > > the file name from the Stream API, arghh). Those usages are bad and require > > a rewrite. > > Are you saying a FileStream knowing its #name or #filename is bad? > > > > >

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by StÃ©phane Ducasse

I will write and send a proposal to the list. Good idea. Stef > Stephane I think you need to sit down and write the Guidelines for Pharo Documentation, explaining the tools, the workflow, the goals, the principles and most importantly where documentation can be found. Post it on pharo website. This way you will save a lot of time from answering questions here . So next time someone asks a relevant question you only post a link to it.

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by StÃ©phane Ducasse

> It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦ With Athens inside the image we will use the pier parser to generate a document tree and render it inside the image. Now one step at a time. >> There are some PEG grammar for markdown, maybe it could be reused so PP can parse it :) >> then one could generate Pier format out of markdown :) What most of you do not get is that. But I do not care about Pier format. I care about a REAL solution that can produce a REAL document tree AND that ***I*** can edit and maintain and enhance so that I can create books. So I'm pragmatic we wrote the seaside book with pier so I took pier because I do not want to write a MD parser and building model and reinventing the wheel. And I do not want to have to learn a new language just to make sure that I can write books. Stef

Nov. 13, 2013

Re: [Pharo-dev] Spec new release :)

by kilon alios

Stephane I think you need to sit down and write the Guidelines for Pharo Documentation, explaining the tools, the workflow, the goals, the principles and most importantly where documentation can be found. Post it on pharo website. This way you will save a lot of time from answering questions here . So next time someone asks a relevant question you only post a link to it. On Wed, Nov 13, 2013 at 9:44 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Nov 13, 2013, at 8:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > Why not generating markdown code from pier code? > > If the whole problem is exposure on the web. Someone has considered > pdf2html or latex2html? > > I did => suicidal tendencies. > The results looks like shit. > > I did not try pdf2html. > > Now pier is a compromise so that normal people can write chapter without > being a latex freaks like us. > > Stef > > > > Maybe my question is naive, I do not know. > > > > On some point, i have tried to generate the roassal documentation from > the Roassal Help, but it makes the maintenance loop heavy: If I want to fix > something in the text, I had to edit the Help in Pharo, generating the > document, compiling into .pdf. Quite heavy it was. At the end, I only > worked on the .tex files. > > > > Alexandre > > > > > > On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> > >> On 13 Nov 2013, at 19:59, Benjamin < > Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > >> > >>> It was a real question, and it feels like you overreacted the answer â¦ > >>> > >>> To me, markdown or pier is a new syntax to learn so I am asking â¦ > >>> To me, doing Pier because you do or because you said to is no really > an argument. > >>> > >>> Then I am open to a real answer but I also see that markdown is > integrated to a lot of tools (github and jekylls by examples) > >>> and that a lot of people knows about markdown. > >>> > >>> This was a real question, not a troll â¦ > >> > >> I like .md as well and yes, the github integration makes it compelling. > >> > >> But one objective argument against Markdown and in favour of Pier is > that the former has no good parser and/or document model and and the latter > does have both, in Pharo. That means that we can write all sorts of tools > ourselves and get things finished, as was proven with the books. > >> > >> There simply isnât any definitive, unambiguous Markdown syntax (the > github variant is only one version). > >> > >>> Ben > >>> > >>> On 13 Nov 2013, at 19:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >>> > >>>> do you really think that I insist of using pier syntax because > >>>> A- I want to lose my time > >>>> B- this is for my ego? > >>>> C- because I'm funny > >>>> D- ... > >>>> > >>>> No seriously? > >>>> > >>>> If you want to get an answer read the thread that yuri raised a while > ago. > >>>> Because we already discussed discussed and discussed it. > >>>> > >>>> I will not write any book in markdown. Now you can try and we see. > >>>> > >>>> Stef > >>>> > >>>>> Stef, what is the advantages of writing it in Pier compared to > markdown ? > >>>>> > >>>>> Ben > >>>>> > >>>> > >>>> > >>> > >> > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > >

Nov. 13, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by Chris Muller

On Wed, Nov 13, 2013 at 1:17 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Exactly, every specialized stream has its specialized API and/or specialized > implementation. > File streams don't even have a name, because they need not to. > You can browse XTFileReadStream and XTFileWriteStream, you won't find such > thing. > The file has a name, the stream does not need any. > Before adding anything to a stream, ask first, why am i going to need this? I agree with what Frank said, but not your suggestion that: > File streams don't even have a name, because they need not to. > If it really need it, the application certainly can retrieve the name from a higher level object (a > FIleReference, FileDirectory or whatever). because doing that means the FileStream is no longer fully-encapsulated. And now for the same method to support a non-FileStream stream, what will be passed as the new FileReference argument? nil? So the code went from stream-delegation to case-logic. This is why organic growth happened in the original Stream hierarchy -- because it was "needed", not random. Not strict, yes, but not "random" either. One final thing to consider about selector "uniformity" is how it can negate the ability to effectively trace code (via senders and implementors). Wow, how many senders of #next...? Stream-composition is cool, though, and I understand that to be a benefit of the stricter API. > 2013/11/13 Frank Shearar <frank.shearar(a)gmail.com> >> >> On 13 November 2013 16:48, Chris Muller <asqueaker(a)gmail.com> wrote: >> > I know nothing about Xtreams but, IMO, this obsession with sterility >> > borders on mental illness. >> > >> > "All sort of un-needed complexity?" That's overstating it a bit, >> > don't you think? >> > >> > So you must really feel stressed that ALL Object's, in fact, have a >> > #name, huh? I admit this seems to push the limits but... >> > >> > what's the point of having any kind of different streams at all then? >> > It's the _differences_ between them that makes composing them useful. >> > Compression, encryption, filtering, sockets, files, circular, etc. >> > You think you'll be able to do all that and get away with all of them >> > having exactly the same API? >> >> They don't have the same API. And they shouldn't. And that's Nicolas' >> whole point. A Stream does not have a name (nor should it - what's the >> name of the compressed output of an audio stream from your >> microphone?). A FileStream can extend this API, and that's fine. But >> keep that out of the Stream API. >> >> So Nicolas is arguing that _difference_ should be reflected in the >> API. File streams have names, but generic streams do not. >> >> As it happens, Xtreams takes a very disciplined approach to this. Some >> streams have positions, and so you can go back. Some can't. This is >> reflected in the API. This is good. >> >> > IMHO working around that, passing extra objects around, sounds more >> > stressful than letting a stream on a _file_ know its filename.. >> >> Mu. Streams have no names. File streams have names. >> >> frank >> >> >> If it really need it, the application certainly can retrieve the name >> >> from a higher level object (a FIleReference, FileDirectory or whatever). >> > >> > How does that solution allow uniformity in stream-using code? >> > >> > On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier >> > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> Yes, a Wrapper would provide the legacy API. >> >> >> >> And yes, the name of a stream should better not be part of the API. >> >> Most stream don't have a name, and adding such API adds all sort of >> >> un-needed complexity. >> >> It's an internal detail that can eventually help for reporting error if >> >> accessible, but nothing more. >> >> >> >> If it really need it, the application certainly can retrieve the name >> >> from a >> >> higher level object (a FIleReference, FileDirectory or whatever). >> >> >> >> >> >> 2013/11/13 Chris Muller <asqueaker(a)gmail.com> >> >>> >> >>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier >> >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> > It's just a matter of selecting a strategy. I've proposed two: >> >>> > A) create a wrapper class for legacy Stream compatibility selectors >> >>> > B) create extensions for Legacy Stream compatibility selectors >> >>> > My preference goes to A) >> >>> >> >>> By wrappers you mean the Xtreams are the innards doing the work and >> >>> the wrappers providing the legacy API? >> >>> >> >>> This would be a great way to test Xtreams. >> >>> >> >>> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek >> >>> > upTo: >> >>> > ...), otherwise we will import all the cruft in Xtream and would go >> >>> > back >> >>> > to >> >>> > our starting point... >> >>> > Once the minimal support written (a few hours should be enough), we >> >>> > should >> >>> > gradually switch each every legacy Stream usage -> Xtream. >> >>> > >> >>> > An area which require more work is those Streams that have mixed >> >>> > conventions >> >>> > (one portion is interpreted as text, another as binary). >> >>> > In theory that's easy, we just have two streams and they both wrap >> >>> > on a >> >>> > low >> >>> > level binary stream, but that means we have to be very cautious with >> >>> > buffers >> >>> > and caches. >> >>> > >> >>> > Another area of work is usage of ugly selectors like name (we try to >> >>> > access >> >>> > the file name from the Stream API, arghh). Those usages are bad and >> >>> > require >> >>> > a rewrite. >> >>> >> >>> Are you saying a FileStream knowing its #name or #filename is bad? >> >>> >> >> >> > >> >

Nov. 13, 2013