Smalltalk › Pharo › Pharo Smalltalk Developers

Packages remodularization

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 10 messages Options
Pavel Krivanek-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Packages remodularization

Pavel Krivanek-3
Hi,

I collected information about classes present in the Pharo-Kernel and
the result is the set of packages that are essential for Pharo. This
is a list of this packages with some small reorganizations proposals.
If the packages will be reorganized, the shrinking process will be
start to be package-oriented and Pharo more modular.

Announcements without Announcements-View category

Collections without KedamaFloatArrayAbstract, Transcripter

Compiler

Exceptions (Exceptions-Extensions category is empty)

Files

Graphics:
        - Graphics-Display Objects without CornerRounder, DisplayText
        - Graphics-Primitives without Pen, PenPointRecorder
        - Graphics-Text (only class TextStyle)
        - Graphics-Transformations without MorphicTransform
       
Kernel

some classes should be moved to Exceptions package:
- BlockCannotReturn
- ArithmeticError
- FloatingPointException

some classes should be moved to a new UIManager package
- ProvideAnswerNotification
- ProgressInitiationException
- ProgressNotification

Multilingual:
        - Multilingual-Encodings
        - Multilingual-ImmPlugin
        - Multilingual-Languages
        - Multilingual-TextConversion
       
some classes should be moved to a new Base64 package
        - MimeConverter
        - Base64MimeConverter
       
ST80-Kernel-Remnants (ValueHolder, StringHolder) should have own
package or to be part of the Kernel package

System:
        - System-Change Notification (all classes)
        - System-Changes (all classes)
        - System-Clipboard (all classes)
        - System-Download (only AbstractLauncher)
        - System-FileRegistry (all classes)
        - System-Finalization (all classes)
        - System-Localization (all classes, at least for now ;-)
        - System-Object Events (all classes)
        - System-Object Storage (all classes)
        - System-Platforms (all classes)
        - System-Pools (all classes)
        - System-Support without AbstractSoundSystem, DummySoundSystem,
FontSubstitutionDuringLoading, Imports, MczInstaller, RealEstateAgent,
SARInstaller, SoundSettings
        - System-Tools only classes MethodReference, BreakPoint, BreakpointManager

(better modularization of System package is welcome)
       
ToolBuilder-Kernel:
        - UIManager class should be in standalone package, maybe together
with DummyUIManager (currently not present in Pharo)
       
Tools:
        - Tools-Changes
                - keep: ChangeSetCategory, ChangeSetCategoryWithParameters,
ElementCategory, ObjectWithDocumentation, StaticChangeSetCategory
                - remove: ChangeList, ChangeListForProjects, ChangeSetBrowser,
ChangeSorter, ClassCommentVersionsBrowser, DualChangeSorter,
VersionsBrowser
        - Tools-Debugger
                - keep: DebuggerMethodMap, DebuggerMethodMapForBlueBookMethods,
DebuggerMethodMapForClosureCompiledMethods, PointerFinder
                - remove: ContextVariablesInspector,. Debugger, MessageTally,
PreDebugWindow, SyntaxError, TimeProfileBrowser
        - class ThreadSafeTranscript (could be moved to Collections-Streams,
this class is a little bit Morphic dependent but this will be fixed)
       
Traits
       
       
It is very simple to change class categories however I suppose that to
fight with MC and automatic updates will be a hell. So maybe we should
prepare a simple reorganization script, upload new packages, prepare
prebuild image and break update process here as several times in the
past. The next step will be some reorganization of method categories.

Cheers,
-- Pavel

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

Re: Packages remodularization

Stéphane Ducasse
Thanks :)

> It is very simple to change class categories however I suppose that to
> fight with MC and automatic updates will be a hell.

Yes but we should succeed :)
but yes if will be probably difficult.

> So maybe we should
> prepare a simple reorganization script, upload new packages, prepare
> prebuild image and break update process here as several times in the
> past. The next step will be some reorganization of method categories.

Stef


> Hi,
>
> I collected information about classes present in the Pharo-Kernel and
> the result is the set of packages that are essential for Pharo. This
> is a list of this packages with some small reorganizations proposals.
> If the packages will be reorganized, the shrinking process will be
> start to be package-oriented and Pharo more modular.
>
> Announcements without Announcements-View category
>
> Collections without KedamaFloatArrayAbstract, Transcripter
>
> Compiler
>
> Exceptions (Exceptions-Extensions category is empty)
>
> Files
>
> Graphics:
> - Graphics-Display Objects without CornerRounder, DisplayText
> - Graphics-Primitives without Pen, PenPointRecorder
> - Graphics-Text (only class TextStyle)
> - Graphics-Transformations without MorphicTransform
>
> Kernel
>
> some classes should be moved to Exceptions package:
> - BlockCannotReturn
> - ArithmeticError
> - FloatingPointException
>
> some classes should be moved to a new UIManager package
> - ProvideAnswerNotification
> - ProgressInitiationException
> - ProgressNotification
>
> Multilingual:
> - Multilingual-Encodings
> - Multilingual-ImmPlugin
> - Multilingual-Languages
> - Multilingual-TextConversion
>
> some classes should be moved to a new Base64 package
> - MimeConverter
> - Base64MimeConverter
>
> ST80-Kernel-Remnants (ValueHolder, StringHolder) should have own
> package or to be part of the Kernel package
>
> System:
> - System-Change Notification (all classes)
> - System-Changes (all classes)
> - System-Clipboard (all classes)
> - System-Download (only AbstractLauncher)
> - System-FileRegistry (all classes)
> - System-Finalization (all classes)
> - System-Localization (all classes, at least for now ;-)
> - System-Object Events (all classes)
> - System-Object Storage (all classes)
> - System-Platforms (all classes)
> - System-Pools (all classes)
> - System-Support without AbstractSoundSystem, DummySoundSystem,
> FontSubstitutionDuringLoading, Imports, MczInstaller, RealEstateAgent,
> SARInstaller, SoundSettings
> - System-Tools only classes MethodReference, BreakPoint, BreakpointManager
>
> (better modularization of System package is welcome)
>
> ToolBuilder-Kernel:
> - UIManager class should be in standalone package, maybe together
> with DummyUIManager (currently not present in Pharo)
>
> Tools:
> - Tools-Changes
> - keep: ChangeSetCategory, ChangeSetCategoryWithParameters,
> ElementCategory, ObjectWithDocumentation, StaticChangeSetCategory
> - remove: ChangeList, ChangeListForProjects, ChangeSetBrowser,
> ChangeSorter, ClassCommentVersionsBrowser, DualChangeSorter,
> VersionsBrowser
> - Tools-Debugger
> - keep: DebuggerMethodMap, DebuggerMethodMapForBlueBookMethods,
> DebuggerMethodMapForClosureCompiledMethods, PointerFinder
> - remove: ContextVariablesInspector,. Debugger, MessageTally,
> PreDebugWindow, SyntaxError, TimeProfileBrowser
> - class ThreadSafeTranscript (could be moved to Collections-Streams,
> this class is a little bit Morphic dependent but this will be fixed)
>
> Traits
>
>
> It is very simple to change class categories however I suppose that to
> fight with MC and automatic updates will be a hell. So maybe we should
> prepare a simple reorganization script, upload new packages, prepare
> prebuild image and break update process here as several times in the
> past. The next step will be some reorganization of method categories.
>
> Cheers,
> -- Pavel
>
> _______________________________________________
> 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
Stéphane Ducasse
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Packages remodularization

Stéphane Ducasse
In reply to this post by Pavel Krivanek-3
Pavel

May be we should start, you publish and I try to integrate changes one by one.

Stef


> Hi,
>
> I collected information about classes present in the Pharo-Kernel and
> the result is the set of packages that are essential for Pharo. This
> is a list of this packages with some small reorganizations proposals.
> If the packages will be reorganized, the shrinking process will be
> start to be package-oriented and Pharo more modular.
>
> Announcements without Announcements-View category
>
> Collections without KedamaFloatArrayAbstract, Transcripter
>
> Compiler
>
> Exceptions (Exceptions-Extensions category is empty)
>
> Files
>
> Graphics:
> - Graphics-Display Objects without CornerRounder, DisplayText
> - Graphics-Primitives without Pen, PenPointRecorder
> - Graphics-Text (only class TextStyle)
> - Graphics-Transformations without MorphicTransform
>
> Kernel
>
> some classes should be moved to Exceptions package:
> - BlockCannotReturn
> - ArithmeticError
> - FloatingPointException
>
> some classes should be moved to a new UIManager package
> - ProvideAnswerNotification
> - ProgressInitiationException
> - ProgressNotification
>
> Multilingual:
> - Multilingual-Encodings
> - Multilingual-ImmPlugin
> - Multilingual-Languages
> - Multilingual-TextConversion
>
> some classes should be moved to a new Base64 package
> - MimeConverter
> - Base64MimeConverter
>
> ST80-Kernel-Remnants (ValueHolder, StringHolder) should have own
> package or to be part of the Kernel package
>
> System:
> - System-Change Notification (all classes)
> - System-Changes (all classes)
> - System-Clipboard (all classes)
> - System-Download (only AbstractLauncher)
> - System-FileRegistry (all classes)
> - System-Finalization (all classes)
> - System-Localization (all classes, at least for now ;-)
> - System-Object Events (all classes)
> - System-Object Storage (all classes)
> - System-Platforms (all classes)
> - System-Pools (all classes)
> - System-Support without AbstractSoundSystem, DummySoundSystem,
> FontSubstitutionDuringLoading, Imports, MczInstaller, RealEstateAgent,
> SARInstaller, SoundSettings
> - System-Tools only classes MethodReference, BreakPoint, BreakpointManager
>
> (better modularization of System package is welcome)
>
> ToolBuilder-Kernel:
> - UIManager class should be in standalone package, maybe together
> with DummyUIManager (currently not present in Pharo)
>
> Tools:
> - Tools-Changes
> - keep: ChangeSetCategory, ChangeSetCategoryWithParameters,
> ElementCategory, ObjectWithDocumentation, StaticChangeSetCategory
> - remove: ChangeList, ChangeListForProjects, ChangeSetBrowser,
> ChangeSorter, ClassCommentVersionsBrowser, DualChangeSorter,
> VersionsBrowser
> - Tools-Debugger
> - keep: DebuggerMethodMap, DebuggerMethodMapForBlueBookMethods,
> DebuggerMethodMapForClosureCompiledMethods, PointerFinder
> - remove: ContextVariablesInspector,. Debugger, MessageTally,
> PreDebugWindow, SyntaxError, TimeProfileBrowser
> - class ThreadSafeTranscript (could be moved to Collections-Streams,
> this class is a little bit Morphic dependent but this will be fixed)
>
> Traits
>
>
> It is very simple to change class categories however I suppose that to
> fight with MC and automatic updates will be a hell. So maybe we should
> prepare a simple reorganization script, upload new packages, prepare
> prebuild image and break update process here as several times in the
> past. The next step will be some reorganization of method categories.
>
> Cheers,
> -- Pavel
>
> _______________________________________________
> 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
Pavel Krivanek-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Packages remodularization

Pavel Krivanek-3
Hi,

the new packages will be:
- AnnouncementsView
- EmergencyEvaluator
- Kedama
- Ffenestri
- GraphicsSupport
- UIManager
- MultilingualSupport
- Base64
- SystemSupport
- Hashing
- SerialPort
- Settings

here's the reorganization code. Of course you can use different package names.

SystemOrganization renameCategory: 'Announcements-Core' toBe: 'Announcements'.
SystemOrganization renameCategory: 'Announcements-View' toBe:
'AnnouncementsView'.

Transcripter category: 'EmergencyEvaluator'.
KedamaFloatArray category: 'Kedama'.

SystemOrganization removeCategory: 'Exceptions-Extensions'.

SystemOrganization renameCategory: 'Graphics-External-Ffenestri' toBe:
'Ffenestri'.
SystemOrganization renameCategory: 'Graphics-Files' toBe:
'GraphicsSupport-Files'.
SystemOrganization renameCategory: 'Graphics-Fonts' toBe:
'GraphicsSupport-Fonts'.
SystemOrganization renameCategory: 'Graphics-Text' toBe: 'GraphicsSupport-Text'.
Pen category: 'GraphicsSupport-Pen'.
PenPointRecorder category: 'GraphicsSupport-Pen'.
CornerRounder category: 'GraphicsSupport-Display Objects'.
DisplayText category: 'GraphicsSupport-Display Objects'.
MorphicTransform category: 'Morphic-Kernel'.

BlockCannotReturn category: 'Exceptions-Kernel'.
ArithmeticError category: 'Exceptions-Kernel'.
FloatingPointException category: 'Exceptions-Kernel'.

ProvideAnswerNotification category: 'UIManager-Support'.
ProgressInitiationException category: 'UIManager-Support'.
ProgressNotification category: 'UIManager-Support'.

SystemOrganization renameCategory: 'Multilingual-Display' toBe:
'MultilingualSupport-Display'.
SystemOrganization renameCategory: 'Multilingual-Editor' toBe:
'MultilingualSupport-Editor'.
SystemOrganization renameCategory: 'Multilingual-Scanning' toBe:
'MultilingualSupport-Scanning'.

MimeConverter category: 'Base64'.
Base64MimeConverter category: 'Base64'.

ValueHolder category: 'Kernel-ValueHolder'.
StringHolder category: 'Kernel-ValueHolder'.
SystemOrganization removeCategory: 'ST80-Kernel-Remnants'.

SystemOrganization renameCategory: 'System-Applications' toBe:
'SystemSupport-Applications'.
SystemOrganization renameCategory: 'System-Digital Signatures' toBe:
'SystemSupport-Digital Signatures'.
SystemOrganization renameCategory: 'System-Download' toBe:
'SystemSupport-Download'.
AbstractLauncher category: 'System-Launcher'.
SystemOrganization renameCategory: 'System-Hashing-Core' toBe: 'Hashing-Core'.
SystemOrganization renameCategory: 'System-Hashing-MD5' toBe: 'Hashing-MD5'.
SystemOrganization renameCategory: 'System-Hashing-SHA1' toBe: 'Hashing-SHA1'.
SystemOrganization renameCategory: 'System-Serial Port' toBe: 'SerialPort'.
SystemOrganization renameCategory: 'Settings-Browser' toBe: 'Settings-Browser'.
SystemOrganization renameCategory: 'System-Settings-Core' toBe: 'Settings-Core'.
SystemOrganization renameCategory: 'System-Settings-Filter' toBe:
'Settings-Filter'.
SystemOrganization renameCategory: 'System-Settings-Style' toBe:
'Settings-Style'.
AbstractSoundSystem category: 'SystemSupport'.
DummySoundSystem category: 'SystemSupport'.
FontSubstitutionDuringLoading category: 'SystemSupport'.
Imports category: 'SystemSupport'.
MczInstaller category: 'SystemSupport'.
RealEstateAgent category: 'SystemSupport'.
SARInstaller category: 'SystemSupport'.
SoundSettings category: 'SystemSupport'.
SystemOrganization renameCategory: 'System-Tools' toBe: 'SystemSupport-Tools'.
MethodReference category: 'System-Tools'.
BreakPoint category: 'System-BreakPoints'.
BreakpointManager category: 'System-BreakPoints'.

UIManager category: 'UIManager'.

ChangeSetCategory category: 'System-ChangeSetCategory'.
ChangeSetCategoryWithParameters category: 'System-ChangeSetCategory'.
ElementCategory category: 'System-ChangeSetCategory'.
ObjectWithDocumentation category: 'System-ChangeSetCategory'.
StaticChangeSetCategory category: 'System-ChangeSetCategory'.

DebuggerMethodMap category: 'System-Debugging'.
DebuggerMethodMapForBlueBookMethods category: 'System-Debugging'.
DebuggerMethodMapForClosureCompiledMethods category: 'System-Debugging'.
PointerFinder category: 'System-Debugging'.

ThreadSafeTranscript category: 'Collections-Streams'.

Cheers,
-- Pavel

On Tue, Mar 2, 2010 at 11:12 AM, Stéphane Ducasse
<[hidden email]> wrote:

> Pavel
>
> May be we should start, you publish and I try to integrate changes one by one.
>
> Stef
>
>
>> Hi,
>>
>> I collected information about classes present in the Pharo-Kernel and
>> the result is the set of packages that are essential for Pharo. This
>> is a list of this packages with some small reorganizations proposals.
>> If the packages will be reorganized, the shrinking process will be
>> start to be package-oriented and Pharo more modular.
>>
>> Announcements without Announcements-View category
>>
>> Collections without KedamaFloatArrayAbstract, Transcripter
>>
>> Compiler
>>
>> Exceptions (Exceptions-Extensions category is empty)
>>
>> Files
>>
>> Graphics:
>>       - Graphics-Display Objects without CornerRounder, DisplayText
>>       - Graphics-Primitives without Pen, PenPointRecorder
>>       - Graphics-Text (only class TextStyle)
>>       - Graphics-Transformations without MorphicTransform
>>
>> Kernel
>>
>> some classes should be moved to Exceptions package:
>> - BlockCannotReturn
>> - ArithmeticError
>> - FloatingPointException
>>
>> some classes should be moved to a new UIManager package
>> - ProvideAnswerNotification
>> - ProgressInitiationException
>> - ProgressNotification
>>
>> Multilingual:
>>       - Multilingual-Encodings
>>       - Multilingual-ImmPlugin
>>       - Multilingual-Languages
>>       - Multilingual-TextConversion
>>
>> some classes should be moved to a new Base64 package
>>       - MimeConverter
>>       - Base64MimeConverter
>>
>> ST80-Kernel-Remnants (ValueHolder, StringHolder) should have own
>> package or to be part of the Kernel package
>>
>> System:
>>       - System-Change Notification (all classes)
>>       - System-Changes (all classes)
>>       - System-Clipboard (all classes)
>>       - System-Download (only AbstractLauncher)
>>       - System-FileRegistry (all classes)
>>       - System-Finalization (all classes)
>>       - System-Localization (all classes, at least for now ;-)
>>       - System-Object Events (all classes)
>>       - System-Object Storage (all classes)
>>       - System-Platforms (all classes)
>>       - System-Pools (all classes)
>>       - System-Support without AbstractSoundSystem, DummySoundSystem,
>> FontSubstitutionDuringLoading, Imports, MczInstaller, RealEstateAgent,
>> SARInstaller, SoundSettings
>>       - System-Tools only classes MethodReference, BreakPoint, BreakpointManager
>>
>> (better modularization of System package is welcome)
>>
>> ToolBuilder-Kernel:
>>       - UIManager class should be in standalone package, maybe together
>> with DummyUIManager (currently not present in Pharo)
>>
>> Tools:
>>       - Tools-Changes
>>               - keep: ChangeSetCategory, ChangeSetCategoryWithParameters,
>> ElementCategory, ObjectWithDocumentation, StaticChangeSetCategory
>>               - remove: ChangeList, ChangeListForProjects, ChangeSetBrowser,
>> ChangeSorter, ClassCommentVersionsBrowser, DualChangeSorter,
>> VersionsBrowser
>>       - Tools-Debugger
>>               - keep: DebuggerMethodMap, DebuggerMethodMapForBlueBookMethods,
>> DebuggerMethodMapForClosureCompiledMethods, PointerFinder
>>               - remove: ContextVariablesInspector,. Debugger, MessageTally,
>> PreDebugWindow, SyntaxError, TimeProfileBrowser
>>       - class ThreadSafeTranscript (could be moved to Collections-Streams,
>> this class is a little bit Morphic dependent but this will be fixed)
>>
>> Traits
>>
>>
>> It is very simple to change class categories however I suppose that to
>> fight with MC and automatic updates will be a hell. So maybe we should
>> prepare a simple reorganization script, upload new packages, prepare
>> prebuild image and break update process here as several times in the
>> past. The next step will be some reorganization of method categories.
>>
>> Cheers,
>> -- Pavel
>>
>> _______________________________________________
>> 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
Lukas Renggli
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Packages remodularization

Lukas Renggli
> SystemOrganization renameCategory: 'Announcements-Core' toBe: 'Announcements'.
> SystemOrganization renameCategory: 'Announcements-View' toBe:
> 'AnnouncementsView'.

Why can't this just be split into two packages 'Announcements-Core'
and 'Announcements-View'?

Furthermore, the code above looses all extension methods. For example
'Announcements-View' extends 'Announcement-Core' in the class
Announcement. Maybe it would be safer to rename packages using the
code we use in Seaside:

renamePackage: oldPackageName to: newPackageName
        "self renamePackage: 'Seaside-Squeak-Development-Core' to:
'Seaside-Pharo-Development-Core'"
       
        | oldPackage newPackage oldWorkingCopy newWorkingCopy |
        oldPackage := PackageInfo named: oldPackageName.
        newPackage := PackageInfo named: newPackageName.
       
        " rename system categories "
        oldPackage systemCategories do: [ :oldCategory |
                | newCategory |
                newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size.
                Smalltalk organization renameCategory: oldCategory toBe: newPackage
systemCategoryPrefix , newCategory ].
       
        " rename method categories "
        oldPackage extensionClasses do: [ :extensionClass |
                (oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol |
                        | newProtocol |
                        newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size.
                        extensionClass organization renameCategory: oldProtocol toBe:
newPackage methodCategoryPrefix , newProtocol ] ].
       
        " update monticello packages "
        oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName).
        newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName).
        newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true.
       
        " test is all methos have been caught "
        oldPackage methods isEmpty
                ifTrue: [ oldWorkingCopy unload. PackageOrganizer default
unregisterPackage: oldPackage ]
                ifFalse: [ self error: 'Some code entities remain in the old
package, please migrate manually.' ]

Otherwise, I completely agree with the proposed refactorings :-)

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

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

Re: Packages remodularization

Pavel Krivanek-3
Hi Lukas,

I only wanted to keep the the original package and don't use any dash
in the package name. Of course we can use your way.

Cheers,
-- Pavel

On Tue, Mar 2, 2010 at 11:50 AM, Lukas Renggli <[hidden email]> wrote:

>> SystemOrganization renameCategory: 'Announcements-Core' toBe: 'Announcements'.
>> SystemOrganization renameCategory: 'Announcements-View' toBe:
>> 'AnnouncementsView'.
>
> Why can't this just be split into two packages 'Announcements-Core'
> and 'Announcements-View'?
>
> Furthermore, the code above looses all extension methods. For example
> 'Announcements-View' extends 'Announcement-Core' in the class
> Announcement. Maybe it would be safer to rename packages using the
> code we use in Seaside:
>
> renamePackage: oldPackageName to: newPackageName
>        "self renamePackage: 'Seaside-Squeak-Development-Core' to:
> 'Seaside-Pharo-Development-Core'"
>
>        | oldPackage newPackage oldWorkingCopy newWorkingCopy |
>        oldPackage := PackageInfo named: oldPackageName.
>        newPackage := PackageInfo named: newPackageName.
>
>        " rename system categories "
>        oldPackage systemCategories do: [ :oldCategory |
>                | newCategory |
>                newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size.
>                Smalltalk organization renameCategory: oldCategory toBe: newPackage
> systemCategoryPrefix , newCategory ].
>
>        " rename method categories "
>        oldPackage extensionClasses do: [ :extensionClass |
>                (oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol |
>                        | newProtocol |
>                        newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size.
>                        extensionClass organization renameCategory: oldProtocol toBe:
> newPackage methodCategoryPrefix , newProtocol ] ].
>
>        " update monticello packages "
>        oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName).
>        newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName).
>        newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true.
>
>        " test is all methos have been caught "
>        oldPackage methods isEmpty
>                ifTrue: [ oldWorkingCopy unload. PackageOrganizer default
> unregisterPackage: oldPackage ]
>                ifFalse: [ self error: 'Some code entities remain in the old
> package, please migrate manually.' ]
>
> Otherwise, I completely agree with the proposed refactorings :-)
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> 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
Lukas Renggli
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Packages remodularization

Lukas Renggli
> I only wanted to keep the the original package and don't use any dash
> in the package name. Of course we can use your way.

Aha ok, then this is fine of course. I don't care about the dashes.

Lukas

>
> Cheers,
> -- Pavel
>
> On Tue, Mar 2, 2010 at 11:50 AM, Lukas Renggli <[hidden email]> wrote:
>>> SystemOrganization renameCategory: 'Announcements-Core' toBe: 'Announcements'.
>>> SystemOrganization renameCategory: 'Announcements-View' toBe:
>>> 'AnnouncementsView'.
>>
>> Why can't this just be split into two packages 'Announcements-Core'
>> and 'Announcements-View'?
>>
>> Furthermore, the code above looses all extension methods. For example
>> 'Announcements-View' extends 'Announcement-Core' in the class
>> Announcement. Maybe it would be safer to rename packages using the
>> code we use in Seaside:
>>
>> renamePackage: oldPackageName to: newPackageName
>>        "self renamePackage: 'Seaside-Squeak-Development-Core' to:
>> 'Seaside-Pharo-Development-Core'"
>>
>>        | oldPackage newPackage oldWorkingCopy newWorkingCopy |
>>        oldPackage := PackageInfo named: oldPackageName.
>>        newPackage := PackageInfo named: newPackageName.
>>
>>        " rename system categories "
>>        oldPackage systemCategories do: [ :oldCategory |
>>                | newCategory |
>>                newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size.
>>                Smalltalk organization renameCategory: oldCategory toBe: newPackage
>> systemCategoryPrefix , newCategory ].
>>
>>        " rename method categories "
>>        oldPackage extensionClasses do: [ :extensionClass |
>>                (oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol |
>>                        | newProtocol |
>>                        newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size.
>>                        extensionClass organization renameCategory: oldProtocol toBe:
>> newPackage methodCategoryPrefix , newProtocol ] ].
>>
>>        " update monticello packages "
>>        oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName).
>>        newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName).
>>        newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true.
>>
>>        " test is all methos have been caught "
>>        oldPackage methods isEmpty
>>                ifTrue: [ oldWorkingCopy unload. PackageOrganizer default
>> unregisterPackage: oldPackage ]
>>                ifFalse: [ self error: 'Some code entities remain in the old
>> package, please migrate manually.' ]
>>
>> Otherwise, I completely agree with the proposed refactorings :-)
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>> _______________________________________________
>> 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
>



--
Lukas Renggli
http://www.lukas-renggli.ch

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

Re: Packages remodularization

Pavel Krivanek-3
We can use dashes in package names, however it's a little bit
confusing and Monticello cannot process it well if one package has
shorter name, for example Announcements and Announcements-View

-- Pavel

On Tue, Mar 2, 2010 at 12:03 PM, Lukas Renggli <[hidden email]> wrote:

>> I only wanted to keep the the original package and don't use any dash
>> in the package name. Of course we can use your way.
>
> Aha ok, then this is fine of course. I don't care about the dashes.
>
> Lukas
>
>>
>> Cheers,
>> -- Pavel
>>
>> On Tue, Mar 2, 2010 at 11:50 AM, Lukas Renggli <[hidden email]> wrote:
>>>> SystemOrganization renameCategory: 'Announcements-Core' toBe: 'Announcements'.
>>>> SystemOrganization renameCategory: 'Announcements-View' toBe:
>>>> 'AnnouncementsView'.
>>>
>>> Why can't this just be split into two packages 'Announcements-Core'
>>> and 'Announcements-View'?
>>>
>>> Furthermore, the code above looses all extension methods. For example
>>> 'Announcements-View' extends 'Announcement-Core' in the class
>>> Announcement. Maybe it would be safer to rename packages using the
>>> code we use in Seaside:
>>>
>>> renamePackage: oldPackageName to: newPackageName
>>>        "self renamePackage: 'Seaside-Squeak-Development-Core' to:
>>> 'Seaside-Pharo-Development-Core'"
>>>
>>>        | oldPackage newPackage oldWorkingCopy newWorkingCopy |
>>>        oldPackage := PackageInfo named: oldPackageName.
>>>        newPackage := PackageInfo named: newPackageName.
>>>
>>>        " rename system categories "
>>>        oldPackage systemCategories do: [ :oldCategory |
>>>                | newCategory |
>>>                newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size.
>>>                Smalltalk organization renameCategory: oldCategory toBe: newPackage
>>> systemCategoryPrefix , newCategory ].
>>>
>>>        " rename method categories "
>>>        oldPackage extensionClasses do: [ :extensionClass |
>>>                (oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol |
>>>                        | newProtocol |
>>>                        newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size.
>>>                        extensionClass organization renameCategory: oldProtocol toBe:
>>> newPackage methodCategoryPrefix , newProtocol ] ].
>>>
>>>        " update monticello packages "
>>>        oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName).
>>>        newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName).
>>>        newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true.
>>>
>>>        " test is all methos have been caught "
>>>        oldPackage methods isEmpty
>>>                ifTrue: [ oldWorkingCopy unload. PackageOrganizer default
>>> unregisterPackage: oldPackage ]
>>>                ifFalse: [ self error: 'Some code entities remain in the old
>>> package, please migrate manually.' ]
>>>
>>> Otherwise, I completely agree with the proposed refactorings :-)
>>>
>>> Lukas
>>>
>>> --
>>> Lukas Renggli
>>> http://www.lukas-renggli.ch
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> 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
Mariano Martinez Peck
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Packages remodularization

Mariano Martinez Peck


On Tue, Mar 2, 2010 at 12:13 PM, Pavel Krivanek <[hidden email]> wrote:
We can use dashes in package names, however it's a little bit
confusing and Monticello cannot process it well if one package has
shorter name, for example Announcements and Announcements-View

Yes, I suffered that several times. In that case Announcements-View is interpreted as a subcategory in the package Announcements
but not as a separate package Announcements-View
 

-- Pavel

On Tue, Mar 2, 2010 at 12:03 PM, Lukas Renggli <[hidden email]> wrote:
>> I only wanted to keep the the original package and don't use any dash
>> in the package name. Of course we can use your way.
>
> Aha ok, then this is fine of course. I don't care about the dashes.
>
> Lukas
>
>>
>> Cheers,
>> -- Pavel
>>
>> On Tue, Mar 2, 2010 at 11:50 AM, Lukas Renggli <[hidden email]> wrote:
>>>> SystemOrganization renameCategory: 'Announcements-Core' toBe: 'Announcements'.
>>>> SystemOrganization renameCategory: 'Announcements-View' toBe:
>>>> 'AnnouncementsView'.
>>>
>>> Why can't this just be split into two packages 'Announcements-Core'
>>> and 'Announcements-View'?
>>>
>>> Furthermore, the code above looses all extension methods. For example
>>> 'Announcements-View' extends 'Announcement-Core' in the class
>>> Announcement. Maybe it would be safer to rename packages using the
>>> code we use in Seaside:
>>>
>>> renamePackage: oldPackageName to: newPackageName
>>>        "self renamePackage: 'Seaside-Squeak-Development-Core' to:
>>> 'Seaside-Pharo-Development-Core'"
>>>
>>>        | oldPackage newPackage oldWorkingCopy newWorkingCopy |
>>>        oldPackage := PackageInfo named: oldPackageName.
>>>        newPackage := PackageInfo named: newPackageName.
>>>
>>>        " rename system categories "
>>>        oldPackage systemCategories do: [ :oldCategory |
>>>                | newCategory |
>>>                newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size.
>>>                Smalltalk organization renameCategory: oldCategory toBe: newPackage
>>> systemCategoryPrefix , newCategory ].
>>>
>>>        " rename method categories "
>>>        oldPackage extensionClasses do: [ :extensionClass |
>>>                (oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol |
>>>                        | newProtocol |
>>>                        newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size.
>>>                        extensionClass organization renameCategory: oldProtocol toBe:
>>> newPackage methodCategoryPrefix , newProtocol ] ].
>>>
>>>        " update monticello packages "
>>>        oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName).
>>>        newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName).
>>>        newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true.
>>>
>>>        " test is all methos have been caught "
>>>        oldPackage methods isEmpty
>>>                ifTrue: [ oldWorkingCopy unload. PackageOrganizer default
>>> unregisterPackage: oldPackage ]
>>>                ifFalse: [ self error: 'Some code entities remain in the old
>>> package, please migrate manually.' ]
>>>
>>> Otherwise, I completely agree with the proposed refactorings :-)
>>>
>>> Lukas
>>>
>>> --
>>> Lukas Renggli
>>> http://www.lukas-renggli.ch
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> 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
Mariano Martinez Peck
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Packages remodularization

Mariano Martinez Peck
This is invaluable useful information...I just created http://code.google.com/p/pharo/issues/detail?id=2105
so that not to forget about this email.

cheers

mariano

On Tue, Mar 2, 2010 at 12:15 PM, Mariano Martinez Peck <[hidden email]> wrote:


On Tue, Mar 2, 2010 at 12:13 PM, Pavel Krivanek <[hidden email]> wrote:
We can use dashes in package names, however it's a little bit
confusing and Monticello cannot process it well if one package has
shorter name, for example Announcements and Announcements-View

Yes, I suffered that several times. In that case Announcements-View is interpreted as a subcategory in the package Announcements
but not as a separate package Announcements-View
 

-- Pavel

On Tue, Mar 2, 2010 at 12:03 PM, Lukas Renggli <[hidden email]> wrote:
>> I only wanted to keep the the original package and don't use any dash
>> in the package name. Of course we can use your way.
>
> Aha ok, then this is fine of course. I don't care about the dashes.
>
> Lukas
>
>>
>> Cheers,
>> -- Pavel
>>
>> On Tue, Mar 2, 2010 at 11:50 AM, Lukas Renggli <[hidden email]> wrote:
>>>> SystemOrganization renameCategory: 'Announcements-Core' toBe: 'Announcements'.
>>>> SystemOrganization renameCategory: 'Announcements-View' toBe:
>>>> 'AnnouncementsView'.
>>>
>>> Why can't this just be split into two packages 'Announcements-Core'
>>> and 'Announcements-View'?
>>>
>>> Furthermore, the code above looses all extension methods. For example
>>> 'Announcements-View' extends 'Announcement-Core' in the class
>>> Announcement. Maybe it would be safer to rename packages using the
>>> code we use in Seaside:
>>>
>>> renamePackage: oldPackageName to: newPackageName
>>>        "self renamePackage: 'Seaside-Squeak-Development-Core' to:
>>> 'Seaside-Pharo-Development-Core'"
>>>
>>>        | oldPackage newPackage oldWorkingCopy newWorkingCopy |
>>>        oldPackage := PackageInfo named: oldPackageName.
>>>        newPackage := PackageInfo named: newPackageName.
>>>
>>>        " rename system categories "
>>>        oldPackage systemCategories do: [ :oldCategory |
>>>                | newCategory |
>>>                newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size.
>>>                Smalltalk organization renameCategory: oldCategory toBe: newPackage
>>> systemCategoryPrefix , newCategory ].
>>>
>>>        " rename method categories "
>>>        oldPackage extensionClasses do: [ :extensionClass |
>>>                (oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol |
>>>                        | newProtocol |
>>>                        newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size.
>>>                        extensionClass organization renameCategory: oldProtocol toBe:
>>> newPackage methodCategoryPrefix , newProtocol ] ].
>>>
>>>        " update monticello packages "
>>>        oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName).
>>>        newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName).
>>>        newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true.
>>>
>>>        " test is all methos have been caught "
>>>        oldPackage methods isEmpty
>>>                ifTrue: [ oldWorkingCopy unload. PackageOrganizer default
>>> unregisterPackage: oldPackage ]
>>>                ifFalse: [ self error: 'Some code entities remain in the old
>>> package, please migrate manually.' ]
>>>
>>> Otherwise, I completely agree with the proposed refactorings :-)
>>>
>>> Lukas
>>>
>>> --
>>> Lukas Renggli
>>> http://www.lukas-renggli.ch
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> 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
Free forum by Nabble Edit this page