Package names

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

Package names

Torsten Bergmann
Shouldnt we rename some packages/class categories:

"PolymorphSystemSettings" -> "Polymorph-SystemSettings"
"CompilerSystemSettings" -> "Compiler-SystemSettings"
...

so they would align with existing ones?

Bye
T.
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Package names

Marcus Denker-4

On Jan 11, 2010, at 2:36 PM, Torsten Bergmann wrote:

> Shouldnt we rename some packages/class categories:
>
> "PolymorphSystemSettings" -> "Polymorph-SystemSettings"
> "CompilerSystemSettings" -> "Compiler-SystemSettings"
> ...
>
> so they would align with existing ones?
>

The problem is that with PackageInfo, Compiler-SystemSettings ist part of Compiler.
And that leads to very strange effects (klasses are part of two packages).

The idea is that the settings packages can be unloaded.... there are no dependencies
from the system the settings.

        Marcus
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Package names

Stéphane Ducasse
But marcus the - does not change anything this is not a special character
if we want to avoid to have
PolymorphSystemSettings to be save with Polymorph as well (berk)
we have to follow

SystemSettings-Polymorph I guess.
Or we should have

Compiler out
and
Compiler-Core
Compiler-SystemSettings

Stef

On Jan 11, 2010, at 2:44 PM, Marcus Denker wrote:

>
> On Jan 11, 2010, at 2:36 PM, Torsten Bergmann wrote:
>
>> Shouldnt we rename some packages/class categories:
>>
>> "PolymorphSystemSettings" -> "Polymorph-SystemSettings"
>> "CompilerSystemSettings" -> "Compiler-SystemSettings"
>> ...
>>
>> so they would align with existing ones?
>>
>
> The problem is that with PackageInfo, Compiler-SystemSettings ist part of Compiler.
> And that leads to very strange effects (klasses are part of two packages).
>
> The idea is that the settings packages can be unloaded.... there are no dependencies
> from the system the settings.
>
> Marcus
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Package names

Alain Plantec-4
Stéphane Ducasse a écrit :

> But marcus the - does not change anything this is not a special character
> if we want to avoid to have
> PolymorphSystemSettings to be save with Polymorph as well (berk)
> we have to follow
>
> SystemSettings-Polymorph I guess.
> Or we should have
>
> Compiler out
> and
> Compiler-Core
> Compiler-SystemSettings
>  
We adopted the same naming rule as for tests.
We have NetworkSystemSettings as we have NetworkTests etc...
If we re-adopt the XXXX-SystemSettings naming rule, then
package XXXX should not be present because of the problem Marcus noticed.

Alain

> Stef
>
> On Jan 11, 2010, at 2:44 PM, Marcus Denker wrote:
>
>  
>> On Jan 11, 2010, at 2:36 PM, Torsten Bergmann wrote:
>>
>>    
>>> Shouldnt we rename some packages/class categories:
>>>
>>> "PolymorphSystemSettings" -> "Polymorph-SystemSettings"
>>> "CompilerSystemSettings" -> "Compiler-SystemSettings"
>>> ...
>>>
>>> so they would align with existing ones?
>>>
>>>      
>> The problem is that with PackageInfo, Compiler-SystemSettings ist part of Compiler.
>> And that leads to very strange effects (klasses are part of two packages).
>>
>> The idea is that the settings packages can be unloaded.... there are no dependencies
>> from the system the settings.
>>
>> Marcus
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>    
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>  


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project