I don't like the Squeak encoders with all the basicNext & co complications, it cries for rewriting. In Xtreams, I just included a compatibility layer for legacy text converters, because it was the fastest ROI. But in my pre-Xtreams attempt, I previously started rewriting the most common (UTF8 & UTF16) - see http://www.squeaksource.com/XTream.html. I saw that you did the same in Zn, so I agree that it is the way to go. I'd just like those classes to loose their XT or Zn prefix, they are common stuff...
2013/11/20 Frank Shearar <[email protected]> > On 20 November 2013 16:13, Sven Van Caekenberghe <[email protected]> wrote: > > Hi Nicolas, > > > > On 19 Nov 2013, at 23:50, Nicolas Cellier < > [email protected]> wrote: > > > >> For the OpalCompiler support, I have simply added the compiler method > in Xtreams-Parsing because it does not conflict with anything else, I have > the feeling that this is bearable… > > > > OK > > > >> I have also added a NotFoundError subclass of NotFound in > Xtreams-support. > >> It's not ideal. That also means that bleeding-edge will not load in > Squeak 4.4 or older, and maybe not elder version of Pharo… > >> Maybe I could have changed NotFoundError reference into NotFound? > > > > NotFound is in Pharo 2.0 as well. > > > > I wonder if it is really necessary to use the VW name/alias, as it is > not referenced, but OK, it could be. I don’t think it is as much part of > the API as Incomplete is. > > > >> In the future, or if we really want a bleeding edge in elder images, we > may have to fork the Xtreams-support, but as long as we can, it's better to > avoid it. > > > > I think that it would be good to keep this a cross platform project (as > it spans multiple platforms already). But that requires effort (at least, > basic interest, maintenance from multiple people on different platforms). > Fuel proves that it can be done. > > Indeed! > > > I think it is unavoidable to have some specific code per platform, > especially in Support. But indeed, not for the sake of it. > > > > I was looking around in the source code and saw some places where I > could imagine things being done differently (ZnCharacterEncoders in Pharo > are properly Character <> Binary). > > > > BTW, does TerminalsFileSystem work on Squeak or is it Pharo specific. > Because FileUrl is on its way out (replaced by ZnUrl). The #reading, > #writing, #appending messages on FileUrl, in their current implementation, > strike me as a bit out of place (as far as I can see, they are not in the > VW code either). I mean, I could image #reading or #writing am HTTP Url as > well, though that would not necessarily the best design. Doing a > #asFileReference in between is acceptable and clearer. > > It's Pharo specific at the moment AFAICT because it refers to > FileHandle and FileReference, while the upstream repo uses > FSFileHandle and FSFileReference. The conversation's partly at > https://code.google.com/p/xtreams/issues/detail?id=2 > > > Are there any areas in the port of Xtreams that need more work, or do > you consider the current situation as complete enough ? In other words, is > there a todo list ? > > > > Are there version differences with the VW code, and how do you see that > evolving ? > > Without answering for Nicolas, > https://code.google.com/p/xtreams/issues/detail?id=3 has Martin > Kobetic saying > > <quote> > Regarding integration, I'd say getting the agreement of the > Squeak/Pharo group should suffice to get it into the Pharo/Squeak > port. Hopefully we will get a reasonable setup for crosspolination > among the dialects eventually, but until then I'd hate to see > evolution hampered because e.g. VW is declared the reference > implementation and nothing is "officially" accepted until VW has it or > some silly rule like that. > > I would only suggest to exercise restraint and avoid uncontrolled > growth of the core framework as a general principle. Only things that > are generally useful and that provide more than a marginal benefit > should be added to the core. It's perfectly fine to make special > purpose streams, and the core framework must always preserve the ease > of doing that, but those streams themselves should live in their > respective projects. > </quote> > > frank > > > Sven > > > >> 2013/11/19 Sven Van Caekenberghe <[email protected]> > >> > >> On 18 Nov 2013, at 22:33, Nicolas Cellier < > [email protected]> wrote: > >> > >> > Ah, NotFoundError is also undeclared in Squeak, it is the VisualWorks > class name. > >> > It could go into Xtreams-Support... > >> > >> OK, are you going to check this in, or should I ? > >> > >> How are we going to deal with platform specific stuff (like the Opal > compiler switch) ? > >> > >> Sven > >> > > > > > >
