platform-specific packages?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

platform-specific packages?

Chris Muller-4
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".

Reply | Threaded
Open this post in threaded view
|

Re: platform-specific packages?

Miguel Cobá
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




Reply | Threaded
Open this post in threaded view
|

Re: platform-specific packages?

Dale Henrichs

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".
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: platform-specific packages?

Miguel Cobá
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




Reply | Threaded
Open this post in threaded view
|

Re: platform-specific packages?

Chris Muller-3
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".
>>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: platform-specific packages?

Miguel Cobá
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