[Pharo-project] Packages remodularization
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 <renggli@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <renggli@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
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 <renggli@gmail.com> 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 <renggli@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Mar 2, 2010 at 12:13 PM, Pavel Krivanek <pavel.krivanek@gmail.com>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 <renggli@gmail.com> 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 <renggli@gmail.com>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 < marianopeck@gmail.com> wrote:
On Tue, Mar 2, 2010 at 12:13 PM, Pavel Krivanek <pavel.krivanek@gmail.com>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 <renggli@gmail.com> 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 <renggli@gmail.com>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Lukas Renggli -
Mariano Martinez Peck -
Pavel Krivanek -
Stéphane Ducasse