What is the best-practice for structuring a collection of MC packages
containing for platform-independent portions? For example, I currently have "Magma client' which has code specific to Squeak. So I made a new package: Magma client-Squeak And then renamed the method-extension category from "*magma client" to "*magma client-squeak". Unfortunately, PackageInfo considers #isYourClassExtension: to be true even if only the "core" package name matches the _prefix_ of the extension category name ("*magma client-squeak"), causing those extensions end up in two packages; "Magma client" as well as "Magma client-Squeak". |
This may help
http://code.google.com/p/seaside/wiki/PackageNaming. Also, if you are repackaging Magma, it would be marvelous to eliminate whitespace from names, if possible. e.g. MagmaClient-Core MagmaClient-Squeak MagmaClient-Pharo MagmaClient-Tests-Common MagmaClient-Tests-Squeak MagmaClient-Tests-Pharo MagmaServer-Core MagmaServer-Squeak MagmaServer-Pharo MagmaServer-Tests-Common MagmaServer-Tests-Squeak MagmaServer-Tests-Pharo Of course most those packages are almost never needed and will be only created if needed to do something different for a given platform that is used by upper layers. But you get the idea. El vie, 15-04-2011 a las 14:24 -0500, Chris Muller escribió: > What is the best-practice for structuring a collection of MC packages > containing for platform-independent portions? > > For example, I currently have "Magma client' which has code specific > to Squeak. So I made a new package: > > Magma client-Squeak > > And then renamed the method-extension category from "*magma client" to > "*magma client-squeak". > > Unfortunately, PackageInfo considers #isYourClassExtension: to be true > even if only the "core" package name matches the _prefix_ of the > extension category name ("*magma client-squeak"), causing those > extensions end up in two packages; "Magma client" as well as "Magma > client-Squeak". > -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
Miguel's suggestions look okay. Seaside has a slightly different naming convention (http://code.google.com/p/seaside/wiki/PackageNaming) that looks like the following: MagmaClient-Core MagmaClient-Squeak-Core MagmaClient-Pharo-Core MagmaClient-Tests-Core MagmaClient-Tests-Squeak-Core MagmaClient-Tests-Pharo-Core Dale On 04/15/2011 12:51 PM, Miguel Cobá wrote: > This may help > > http://code.google.com/p/seaside/wiki/PackageNaming. > > Also, if you are repackaging Magma, it would be marvelous to eliminate > whitespace from names, if possible. > > e.g. > > MagmaClient-Core > MagmaClient-Squeak > MagmaClient-Pharo > MagmaClient-Tests-Common > MagmaClient-Tests-Squeak > MagmaClient-Tests-Pharo > MagmaServer-Core > MagmaServer-Squeak > MagmaServer-Pharo > MagmaServer-Tests-Common > MagmaServer-Tests-Squeak > MagmaServer-Tests-Pharo > > Of course most those packages are almost never needed and will be only > created if needed to do something different for a given platform that is > used by upper layers. But you get the idea. > > El vie, 15-04-2011 a las 14:24 -0500, Chris Muller escribió: >> What is the best-practice for structuring a collection of MC packages >> containing for platform-independent portions? >> >> For example, I currently have "Magma client' which has code specific >> to Squeak. So I made a new package: >> >> Magma client-Squeak >> >> And then renamed the method-extension category from "*magma client" to >> "*magma client-squeak". >> >> Unfortunately, PackageInfo considers #isYourClassExtension: to be true >> even if only the "core" package name matches the _prefix_ of the >> extension category name ("*magma client-squeak"), causing those >> extensions end up in two packages; "Magma client" as well as "Magma >> client-Squeak". >> > |
Thanks Dale, your version is correct :). I wrote it so fast and put them
wrong Cheers El vie, 15-04-2011 a las 13:41 -0700, Dale Henrichs escribió: > Miguel's suggestions look okay. Seaside has a slightly different naming > convention (http://code.google.com/p/seaside/wiki/PackageNaming) that > looks like the following: > > MagmaClient-Core > MagmaClient-Squeak-Core > MagmaClient-Pharo-Core > > MagmaClient-Tests-Core > MagmaClient-Tests-Squeak-Core > MagmaClient-Tests-Pharo-Core > > Dale > > On 04/15/2011 12:51 PM, Miguel Cobá wrote: > > This may help > > > > http://code.google.com/p/seaside/wiki/PackageNaming. > > > > Also, if you are repackaging Magma, it would be marvelous to eliminate > > whitespace from names, if possible. > > > > e.g. > > > > MagmaClient-Core > > MagmaClient-Squeak > > MagmaClient-Pharo > > MagmaClient-Tests-Common > > MagmaClient-Tests-Squeak > > MagmaClient-Tests-Pharo > > MagmaServer-Core > > MagmaServer-Squeak > > MagmaServer-Pharo > > MagmaServer-Tests-Common > > MagmaServer-Tests-Squeak > > MagmaServer-Tests-Pharo > > > > Of course most those packages are almost never needed and will be only > > created if needed to do something different for a given platform that is > > used by upper layers. But you get the idea. > > > > El vie, 15-04-2011 a las 14:24 -0500, Chris Muller escribió: > >> What is the best-practice for structuring a collection of MC packages > >> containing for platform-independent portions? > >> > >> For example, I currently have "Magma client' which has code specific > >> to Squeak. So I made a new package: > >> > >> Magma client-Squeak > >> > >> And then renamed the method-extension category from "*magma client" to > >> "*magma client-squeak". > >> > >> Unfortunately, PackageInfo considers #isYourClassExtension: to be true > >> even if only the "core" package name matches the _prefix_ of the > >> extension category name ("*magma client-squeak"), causing those > >> extensions end up in two packages; "Magma client" as well as "Magma > >> client-Squeak". > >> > > > -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
In reply to this post by Dale Henrichs
I would of course like to update the names to remove the whitespace
and be more modern and conventional; these names were chosen long before these conventions materialized, and since I'm a human, I chose to use whitespace at that time. Wish I hadn't or the software had told me I shouldn't.. I want to see if I can coax MC into letting "Magma client-cmm.123" be the ancestor of "MagmaClient-Core-cmm.124" without any problems or side-effects... - Chris On Fri, Apr 15, 2011 at 3:41 PM, Dale Henrichs <[hidden email]> wrote: > > Miguel's suggestions look okay. Seaside has a slightly different naming > convention (http://code.google.com/p/seaside/wiki/PackageNaming) that looks > like the following: > > MagmaClient-Core > MagmaClient-Squeak-Core > MagmaClient-Pharo-Core > > MagmaClient-Tests-Core > MagmaClient-Tests-Squeak-Core > MagmaClient-Tests-Pharo-Core > > Dale > > On 04/15/2011 12:51 PM, Miguel Cobá wrote: >> >> This may help >> >> http://code.google.com/p/seaside/wiki/PackageNaming. >> >> Also, if you are repackaging Magma, it would be marvelous to eliminate >> whitespace from names, if possible. >> >> e.g. >> >> MagmaClient-Core >> MagmaClient-Squeak >> MagmaClient-Pharo >> MagmaClient-Tests-Common >> MagmaClient-Tests-Squeak >> MagmaClient-Tests-Pharo >> MagmaServer-Core >> MagmaServer-Squeak >> MagmaServer-Pharo >> MagmaServer-Tests-Common >> MagmaServer-Tests-Squeak >> MagmaServer-Tests-Pharo >> >> Of course most those packages are almost never needed and will be only >> created if needed to do something different for a given platform that is >> used by upper layers. But you get the idea. >> >> El vie, 15-04-2011 a las 14:24 -0500, Chris Muller escribió: >>> >>> What is the best-practice for structuring a collection of MC packages >>> containing for platform-independent portions? >>> >>> For example, I currently have "Magma client' which has code specific >>> to Squeak. So I made a new package: >>> >>> Magma client-Squeak >>> >>> And then renamed the method-extension category from "*magma client" to >>> "*magma client-squeak". >>> >>> Unfortunately, PackageInfo considers #isYourClassExtension: to be true >>> even if only the "core" package name matches the _prefix_ of the >>> extension category name ("*magma client-squeak"), causing those >>> extensions end up in two packages; "Magma client" as well as "Magma >>> client-Squeak". >>> >> > > > |
El vie, 15-04-2011 a las 15:53 -0500, Chris Muller escribió:
> I would of course like to update the names to remove the whitespace > and be more modern and conventional; these names were chosen long > before these conventions materialized, and since I'm a human, I chose > to use whitespace at that time. Wish I hadn't or the software had > told me I shouldn't.. > > I want to see if I can coax MC into letting "Magma client-cmm.123" be > the ancestor of "MagmaClient-Core-cmm.124" without any problems or > side-effects... I hope none be found. From the readings of your posts about the MC refactoring you did, I had the impression that the name means nothing to MC, and is the info contained inside the mcz what matter. But I'm at most a casual MC user and not at all a MC connaisseur. Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
Free forum by Nabble | Edit this page |