Splitting an existing package
Locked
Splitting an existing package
 
|
I would like to split the Compression package into its two constituent
subpackages, Compression-Archives and Compression-Streams. Files depends on things in Compression-Archives, and Compression-Streams depends on Files. If I can split the package and replace it with the two subpackages, I can untangle this cyclic dependency. But how would I actually do this? I've tried making two packages, for instance. However, the classes still remain in Compression... as you can see if you try to unload the old Compression package. frank |
Re: Splitting an existing package
|
|
On 16 July 2013 22:30, Frank Shearar <[hidden email]> wrote:
> I would like to split the Compression package into its two constituent > subpackages, Compression-Archives and Compression-Streams. > > Files depends on things in Compression-Archives, and > Compression-Streams depends on Files. If I can split the package and > replace it with the two subpackages, I can untangle this cyclic > dependency. > > But how would I actually do this? I've tried making two packages, for > instance. However, the classes still remain in Compression... as you > can see if you try to unload the old Compression package. One possible way goes something like this: * Add CompressionArchives and CompressionStream packages corresponding to the hyphenated system categories * Push a new config map with the "new" packages * Push the empty Compression package * Remove the Compression package using a config map * Rename CompressionArchives to Compression-Archives and same for Stream * Push a third config map removing Compression and adding Compression-Archives and Compression-Stream > frank |
|
|
So, after step 1, you also need to hunt down the various extensions - in FileStream and other places - that is part of the Compression package, and move them to one of the new packages. Otherwise you innadvertantly remove those methods. (Currently all of these are just under *Compression - no sub-category...) -Chris On Tue, Jul 16, 2013 at 2:39 PM, Frank Shearar <[hidden email]> wrote:
|
Re: Splitting an existing package
|
|
Why should Files depend on anything in Compression? The image I'm in
now reveals just two puny little methods causing Files to depend on Compression. If you move CompressedSourceStream to Compression (hey that makes sense!), as well as FileStream class>>#fileIn:, then we could be rid of the cycle that way. On Tue, Jul 16, 2013 at 6:52 PM, Chris Cunningham <[hidden email]> wrote: > So, after step 1, you also need to hunt down the various extensions - in > FileStream and other places - that is part of the Compression package, and > move them to one of the new packages. Otherwise you innadvertantly remove > those methods. (Currently all of these are just under *Compression - no > sub-category...) > > -Chris > > > On Tue, Jul 16, 2013 at 2:39 PM, Frank Shearar <[hidden email]> > wrote: >> >> On 16 July 2013 22:30, Frank Shearar <[hidden email]> wrote: >> > I would like to split the Compression package into its two constituent >> > subpackages, Compression-Archives and Compression-Streams. >> > >> > Files depends on things in Compression-Archives, and >> > Compression-Streams depends on Files. If I can split the package and >> > replace it with the two subpackages, I can untangle this cyclic >> > dependency. >> > >> > But how would I actually do this? I've tried making two packages, for >> > instance. However, the classes still remain in Compression... as you >> > can see if you try to unload the old Compression package. >> >> One possible way goes something like this: >> * Add CompressionArchives and CompressionStream packages corresponding >> to the hyphenated system categories >> * Push a new config map with the "new" packages >> * Push the empty Compression package >> * Remove the Compression package using a config map >> * Rename CompressionArchives to Compression-Archives and same for Stream >> * Push a third config map removing Compression and adding >> Compression-Archives and Compression-Stream >> >> > frank >> > > > > |
Re: Splitting an existing package
|
|
I'm not sure which is the better approach, but I do know that splitting
a package into subpackages can be confusing for someone browsing the repository and trying to figure out what packages to load. For that reason I would be inlined to favor Chris' suggestion. I learned this the hard way by splitting OSProcess into sub-packages. It seemed like a good idea at the time, but all it does is clutter up the repository and make it harder for people to figure out what to load. Oops. Dave On Tue, Jul 16, 2013 at 07:19:46PM -0500, Chris Muller wrote: > Why should Files depend on anything in Compression? The image I'm in > now reveals just two puny little methods causing Files to depend on > Compression. > > If you move CompressedSourceStream to Compression (hey that makes > sense!), as well as FileStream class>>#fileIn:, then we could be rid > of the cycle that way. > > > > > On Tue, Jul 16, 2013 at 6:52 PM, Chris Cunningham > <[hidden email]> wrote: > > So, after step 1, you also need to hunt down the various extensions - in > > FileStream and other places - that is part of the Compression package, and > > move them to one of the new packages. Otherwise you innadvertantly remove > > those methods. (Currently all of these are just under *Compression - no > > sub-category...) > > > > -Chris > > > > > > On Tue, Jul 16, 2013 at 2:39 PM, Frank Shearar <[hidden email]> > > wrote: > >> > >> On 16 July 2013 22:30, Frank Shearar <[hidden email]> wrote: > >> > I would like to split the Compression package into its two constituent > >> > subpackages, Compression-Archives and Compression-Streams. > >> > > >> > Files depends on things in Compression-Archives, and > >> > Compression-Streams depends on Files. If I can split the package and > >> > replace it with the two subpackages, I can untangle this cyclic > >> > dependency. > >> > > >> > But how would I actually do this? I've tried making two packages, for > >> > instance. However, the classes still remain in Compression... as you > >> > can see if you try to unload the old Compression package. > >> > >> One possible way goes something like this: > >> * Add CompressionArchives and CompressionStream packages corresponding > >> to the hyphenated system categories > >> * Push a new config map with the "new" packages > >> * Push the empty Compression package > >> * Remove the Compression package using a config map > >> * Rename CompressionArchives to Compression-Archives and same for Stream > >> * Push a third config map removing Compression and adding > >> Compression-Archives and Compression-Stream > >> > >> > frank > >> > > > > > > > > |
Re: Splitting an existing package
|
|
On 17 July 2013 03:54, David T. Lewis <[hidden email]> wrote:
> I'm not sure which is the better approach, but I do know that splitting > a package into subpackages can be confusing for someone browsing the > repository and trying to figure out what packages to load. For that reason > I would be inlined to favor Chris' suggestion. > > I learned this the hard way by splitting OSProcess into sub-packages. It > seemed like a good idea at the time, but all it does is clutter up the > repository and make it harder for people to figure out what to load. Oops. Ah, but OSProcess has the luxury of being on _top_ of the maze of twisty cyclic dependencies, all alike! frank > Dave > > On Tue, Jul 16, 2013 at 07:19:46PM -0500, Chris Muller wrote: >> Why should Files depend on anything in Compression? The image I'm in >> now reveals just two puny little methods causing Files to depend on >> Compression. >> >> If you move CompressedSourceStream to Compression (hey that makes >> sense!), as well as FileStream class>>#fileIn:, then we could be rid >> of the cycle that way. >> >> >> >> >> On Tue, Jul 16, 2013 at 6:52 PM, Chris Cunningham >> <[hidden email]> wrote: >> > So, after step 1, you also need to hunt down the various extensions - in >> > FileStream and other places - that is part of the Compression package, and >> > move them to one of the new packages. Otherwise you innadvertantly remove >> > those methods. (Currently all of these are just under *Compression - no >> > sub-category...) >> > >> > -Chris >> > >> > >> > On Tue, Jul 16, 2013 at 2:39 PM, Frank Shearar <[hidden email]> >> > wrote: >> >> >> >> On 16 July 2013 22:30, Frank Shearar <[hidden email]> wrote: >> >> > I would like to split the Compression package into its two constituent >> >> > subpackages, Compression-Archives and Compression-Streams. >> >> > >> >> > Files depends on things in Compression-Archives, and >> >> > Compression-Streams depends on Files. If I can split the package and >> >> > replace it with the two subpackages, I can untangle this cyclic >> >> > dependency. >> >> > >> >> > But how would I actually do this? I've tried making two packages, for >> >> > instance. However, the classes still remain in Compression... as you >> >> > can see if you try to unload the old Compression package. >> >> >> >> One possible way goes something like this: >> >> * Add CompressionArchives and CompressionStream packages corresponding >> >> to the hyphenated system categories >> >> * Push a new config map with the "new" packages >> >> * Push the empty Compression package >> >> * Remove the Compression package using a config map >> >> * Rename CompressionArchives to Compression-Archives and same for Stream >> >> * Push a third config map removing Compression and adding >> >> Compression-Archives and Compression-Stream >> >> >> >> > frank >> >> >> > >> > >> > >> > > |
Re: Splitting an existing package
|
|
In reply to this post by cbc
On 17 July 2013 00:52, Chris Cunningham <[hidden email]> wrote:
> So, after step 1, you also need to hunt down the various extensions - in > FileStream and other places - that is part of the Compression package, and > move them to one of the new packages. Otherwise you innadvertantly remove > those methods. (Currently all of these are just under *Compression - no > sub-category...) Thanks. That's a very, very good point. So a sanity check where I count the number of expected classes and methods in Compression would be in order: after the split the sums of classes and methods in the subpackages should match! frank > -Chris > > > On Tue, Jul 16, 2013 at 2:39 PM, Frank Shearar <[hidden email]> > wrote: >> >> On 16 July 2013 22:30, Frank Shearar <[hidden email]> wrote: >> > I would like to split the Compression package into its two constituent >> > subpackages, Compression-Archives and Compression-Streams. >> > >> > Files depends on things in Compression-Archives, and >> > Compression-Streams depends on Files. If I can split the package and >> > replace it with the two subpackages, I can untangle this cyclic >> > dependency. >> > >> > But how would I actually do this? I've tried making two packages, for >> > instance. However, the classes still remain in Compression... as you >> > can see if you try to unload the old Compression package. >> >> One possible way goes something like this: >> * Add CompressionArchives and CompressionStream packages corresponding >> to the hyphenated system categories >> * Push a new config map with the "new" packages >> * Push the empty Compression package >> * Remove the Compression package using a config map >> * Rename CompressionArchives to Compression-Archives and same for Stream >> * Push a third config map removing Compression and adding >> Compression-Archives and Compression-Stream >> >> > frank >> > > > > |
Re: Splitting an existing package
|
|
In reply to this post by Chris Muller-3
On 17 July 2013 01:19, Chris Muller <[hidden email]> wrote:
> Why should Files depend on anything in Compression? The image I'm in > now reveals just two puny little methods causing Files to depend on > Compression. Compression depends on Files because of things like ZipArchive. That's a fairly reasonable dependency. Files depends on Compression because CompressedSourceStream and FileStream use GZipReadStream and GZipWriteStream. Other than causing a cycle, this dependency's not terrible either. It's just that the two together is highly problematic. frank > If you move CompressedSourceStream to Compression (hey that makes > sense!), as well as FileStream class>>#fileIn:, then we could be rid > of the cycle that way. > > > > > On Tue, Jul 16, 2013 at 6:52 PM, Chris Cunningham > <[hidden email]> wrote: >> So, after step 1, you also need to hunt down the various extensions - in >> FileStream and other places - that is part of the Compression package, and >> move them to one of the new packages. Otherwise you innadvertantly remove >> those methods. (Currently all of these are just under *Compression - no >> sub-category...) >> >> -Chris >> >> >> On Tue, Jul 16, 2013 at 2:39 PM, Frank Shearar <[hidden email]> >> wrote: >>> >>> On 16 July 2013 22:30, Frank Shearar <[hidden email]> wrote: >>> > I would like to split the Compression package into its two constituent >>> > subpackages, Compression-Archives and Compression-Streams. >>> > >>> > Files depends on things in Compression-Archives, and >>> > Compression-Streams depends on Files. If I can split the package and >>> > replace it with the two subpackages, I can untangle this cyclic >>> > dependency. >>> > >>> > But how would I actually do this? I've tried making two packages, for >>> > instance. However, the classes still remain in Compression... as you >>> > can see if you try to unload the old Compression package. >>> >>> One possible way goes something like this: >>> * Add CompressionArchives and CompressionStream packages corresponding >>> to the hyphenated system categories >>> * Push a new config map with the "new" packages >>> * Push the empty Compression package >>> * Remove the Compression package using a config map >>> * Rename CompressionArchives to Compression-Archives and same for Stream >>> * Push a third config map removing Compression and adding >>> Compression-Archives and Compression-Stream >>> >>> > frank >>> >> >> >> >> > |
Re: Splitting an existing package
|
|
In reply to this post by Chris Muller-3
On 17 July 2013 01:19, Chris Muller <[hidden email]> wrote:
> Why should Files depend on anything in Compression? The image I'm in > now reveals just two puny little methods causing Files to depend on > Compression. > > If you move CompressedSourceStream to Compression (hey that makes > sense!), as well as FileStream class>>#fileIn:, then we could be rid > of the cycle that way. It's more complicated than that. FileDirectory class >> #openSources:forImage: also uses CompressedSourceStream, so would get pulled into Compression. (This stuff happens because we try use Foo.sources.gz if we can't find Foo.sources. I don't know if there's a nice way of writing a pluggable thing where we segregate the fallback logic and let packages plug into that. That kind of inversion's great for breaking dependencies because higher layer packages just plug into lower layer ones.) frank > On Tue, Jul 16, 2013 at 6:52 PM, Chris Cunningham > <[hidden email]> wrote: >> So, after step 1, you also need to hunt down the various extensions - in >> FileStream and other places - that is part of the Compression package, and >> move them to one of the new packages. Otherwise you innadvertantly remove >> those methods. (Currently all of these are just under *Compression - no >> sub-category...) >> >> -Chris >> >> >> On Tue, Jul 16, 2013 at 2:39 PM, Frank Shearar <[hidden email]> >> wrote: >>> >>> On 16 July 2013 22:30, Frank Shearar <[hidden email]> wrote: >>> > I would like to split the Compression package into its two constituent >>> > subpackages, Compression-Archives and Compression-Streams. >>> > >>> > Files depends on things in Compression-Archives, and >>> > Compression-Streams depends on Files. If I can split the package and >>> > replace it with the two subpackages, I can untangle this cyclic >>> > dependency. >>> > >>> > But how would I actually do this? I've tried making two packages, for >>> > instance. However, the classes still remain in Compression... as you >>> > can see if you try to unload the old Compression package. >>> >>> One possible way goes something like this: >>> * Add CompressionArchives and CompressionStream packages corresponding >>> to the hyphenated system categories >>> * Push a new config map with the "new" packages >>> * Push the empty Compression package >>> * Remove the Compression package using a config map >>> * Rename CompressionArchives to Compression-Archives and same for Stream >>> * Push a third config map removing Compression and adding >>> Compression-Archives and Compression-Stream >>> >>> > frank >>> >> >> >> >> > |
Re: Splitting an existing package
|
|
On 17 July 2013 09:58, Frank Shearar <[hidden email]> wrote:
> On 17 July 2013 01:19, Chris Muller <[hidden email]> wrote: >> Why should Files depend on anything in Compression? The image I'm in >> now reveals just two puny little methods causing Files to depend on >> Compression. >> >> If you move CompressedSourceStream to Compression (hey that makes >> sense!), as well as FileStream class>>#fileIn:, then we could be rid >> of the cycle that way. > > It's more complicated than that. FileDirectory class >> > #openSources:forImage: also uses CompressedSourceStream, so would get > pulled into Compression. > > (This stuff happens because we try use Foo.sources.gz if we can't find > Foo.sources. I don't know if there's a nice way of writing a pluggable > thing where we segregate the fallback logic and let packages plug into > that. That kind of inversion's great for breaking dependencies because > higher layer packages just plug into lower layer ones.) Actually, the whole "system start up" category in FileDirectory is miscategorised. This has nothing to do with generic file stuff. It's specific to handling the sources file on startup and shutdown of an image. Sounds like it belongs in something like System-Files! That small change makes the whole problem go away. frank >> On Tue, Jul 16, 2013 at 6:52 PM, Chris Cunningham >> <[hidden email]> wrote: >>> So, after step 1, you also need to hunt down the various extensions - in >>> FileStream and other places - that is part of the Compression package, and >>> move them to one of the new packages. Otherwise you innadvertantly remove >>> those methods. (Currently all of these are just under *Compression - no >>> sub-category...) >>> >>> -Chris >>> >>> >>> On Tue, Jul 16, 2013 at 2:39 PM, Frank Shearar <[hidden email]> >>> wrote: >>>> >>>> On 16 July 2013 22:30, Frank Shearar <[hidden email]> wrote: >>>> > I would like to split the Compression package into its two constituent >>>> > subpackages, Compression-Archives and Compression-Streams. >>>> > >>>> > Files depends on things in Compression-Archives, and >>>> > Compression-Streams depends on Files. If I can split the package and >>>> > replace it with the two subpackages, I can untangle this cyclic >>>> > dependency. >>>> > >>>> > But how would I actually do this? I've tried making two packages, for >>>> > instance. However, the classes still remain in Compression... as you >>>> > can see if you try to unload the old Compression package. >>>> >>>> One possible way goes something like this: >>>> * Add CompressionArchives and CompressionStream packages corresponding >>>> to the hyphenated system categories >>>> * Push a new config map with the "new" packages >>>> * Push the empty Compression package >>>> * Remove the Compression package using a config map >>>> * Rename CompressionArchives to Compression-Archives and same for Stream >>>> * Push a third config map removing Compression and adding >>>> Compression-Archives and Compression-Stream >>>> >>>> > frank >>>> >>> >>> >>> >>> >> |
Re: Splitting an existing package
|
|
On 7/17/13, Frank Shearar <[hidden email]> wrote:
> On 17 July 2013 09:58, Frank Shearar <[hidden email]> wrote: >> On 17 July 2013 01:19, Chris Muller <[hidden email]> wrote: >>> Why should Files depend on anything in Compression? The image I'm in >>> now reveals just two puny little methods causing Files to depend on >>> Compression. >>> >>> If you move CompressedSourceStream to Compression (hey that makes >>> sense!), as well as FileStream class>>#fileIn:, then we could be rid >>> of the cycle that way. >> >> It's more complicated than that. FileDirectory class >> >> #openSources:forImage: also uses CompressedSourceStream, so would get >> pulled into Compression. >> >> (This stuff happens because we try use Foo.sources.gz if we can't find >> Foo.sources. I don't know if there's a nice way of writing a pluggable >> thing where we segregate the fallback logic and let packages plug into >> that. That kind of inversion's great for breaking dependencies because >> higher layer packages just plug into lower layer ones.) > > Actually, the whole "system start up" category in FileDirectory is > miscategorised. This has nothing to do with generic file stuff. It's > specific to handling the sources file on startup and shutdown of an > image. Sounds like it belongs in something like System-Files! Having this in 'System-Files' makes a lot of sense. -- Hannes > That small change makes the whole problem go away. > > frank > >>> On Tue, Jul 16, 2013 at 6:52 PM, Chris Cunningham >>> <[hidden email]> wrote: >>>> So, after step 1, you also need to hunt down the various extensions - >>>> in >>>> FileStream and other places - that is part of the Compression package, >>>> and >>>> move them to one of the new packages. Otherwise you innadvertantly >>>> remove >>>> those methods. (Currently all of these are just under *Compression - >>>> no >>>> sub-category...) >>>> >>>> -Chris >>>> >>>> >>>> On Tue, Jul 16, 2013 at 2:39 PM, Frank Shearar >>>> <[hidden email]> >>>> wrote: >>>>> >>>>> On 16 July 2013 22:30, Frank Shearar <[hidden email]> wrote: >>>>> > I would like to split the Compression package into its two >>>>> > constituent >>>>> > subpackages, Compression-Archives and Compression-Streams. >>>>> > >>>>> > Files depends on things in Compression-Archives, and >>>>> > Compression-Streams depends on Files. If I can split the package and >>>>> > replace it with the two subpackages, I can untangle this cyclic >>>>> > dependency. >>>>> > >>>>> > But how would I actually do this? I've tried making two packages, >>>>> > for >>>>> > instance. However, the classes still remain in Compression... as you >>>>> > can see if you try to unload the old Compression package. >>>>> >>>>> One possible way goes something like this: >>>>> * Add CompressionArchives and CompressionStream packages corresponding >>>>> to the hyphenated system categories >>>>> * Push a new config map with the "new" packages >>>>> * Push the empty Compression package >>>>> * Remove the Compression package using a config map >>>>> * Rename CompressionArchives to Compression-Archives and same for >>>>> Stream >>>>> * Push a third config map removing Compression and adding >>>>> Compression-Archives and Compression-Stream >>>>> >>>>> > frank >>>>> >>>> >>>> >>>> >>>> >>> > > |
Re: Splitting an existing package
|
|
In reply to this post by Frank Shearar-3
> Compression depends on Files because of things like ZipArchive. That's
> a fairly reasonable dependency. > > Files depends on Compression because CompressedSourceStream and > FileStream use GZipReadStream and GZipWriteStream. Other than causing > a cycle, this dependency's not terrible either. Maybe we should try to think of lower-level packages as the ones closer to the OS. Remember how Smalltalk was supposed to make OS's obsolete by giving access to OS facilities via the programming API. Thinking from that angle, which one, either Files or Compression, would be the one that should be lower level? IMO, it's Files. Accessing the file system is something that should be the responsibility of a single, lower-level package and *compressing* things is an "Application-level" thing. There is no inherent requirement to compress anything, it's an app-level resposnsibility. Therefore, I don't see it as reasonable that Files should depend on anything in Compression. The methods in FileStream which reference GZipReadStream and GZipWriteStream should be moved to Compression. |
Re: Splitting an existing package
|
|
On 7/17/13, Chris Muller <[hidden email]> wrote:
>> Compression depends on Files because of things like ZipArchive. That's >> a fairly reasonable dependency. >> >> Files depends on Compression because CompressedSourceStream and >> FileStream use GZipReadStream and GZipWriteStream. Other than causing >> a cycle, this dependency's not terrible either. > > Maybe we should try to think of lower-level packages as the ones > closer to the OS. Yes. Remember how Smalltalk was supposed to make OS's > obsolete by giving access to OS facilities via the programming API. > > Thinking from that angle, which one, either Files or Compression, > would be the one that should be lower level? > > IMO, it's Files. Yes. Accessing the file system is something that should > be the responsibility of a single, lower-level package Yes. and > *compressing* things is an "Application-level" thing. Yes. > There is no inherent requirement to compress anything, it's an > app-level resposnsibility. Therefore, I don't see it as reasonable > that Files should depend on anything in Compression. Yes. > The methods in FileStream which reference GZipReadStream and > GZipWriteStream should be moved to Compression. Yes. H. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |