January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Undo/Redo [was: Re: Object Buffer (implementation tryout)]

by John M McIntosh

Yes, it's in the category "Sophie-Undo" If I consider the class AbstractUndoRecord We hung 67 subclasses off it, which gives you an idea of the complexity of we what were doing (60 some UI actions), but also the fact it could handle it.. UndoManager class comment: UndoManager manages execution and storing of UndoRecords through #doAndAddRecord:. It allows hierarchical grouping of UndoRecords through #openRecordGroup, #openRecordGroupNamed: and #closeRecordGroup. Undo and redo is invoked by #undo and #redo. See UndoManagerTest for someExamples. Structure: undoHistory OrderedCollection -- holds UndoRecords for undo redoHistory OrderedCollection -- holds UndoRecords for redo maxHistoryLength Integer -- Old UndoRecords in undoHistory are removed to keep it within given limits (0 for no Limit) groupStack OrderedCollection -- temporary dataStructure to manage hierarchical grouping of UndoRecords by #openRecordGroup and closeRecordGroup historyInvalid Boolean -- flag to indicate, that the history is invalid and it must be deleted including the groupStack On 2010-01-12, at 9:52 PM, Martin McClure wrote: > John M McIntosh wrote: > > [...] >> >> PS if anyone is interested the Undo/Redo Logic that Impara did for >> Sophie was very well received, easy to use, and we could build a book >> from scratch >> then undo the entire creation, then redo it. This sounds complex, it >> was. However the framework made it easy, one piece at a time... >> Perhaps someone should harvest that since it *was* generic. > > Ooh, nice. A good undo/redo framework would be *so* *very* good to have. > I'm afraid I can't be the one to harvest it, not anytime soon anyhow, > but I hope someone picks it up. > > > Regards, > > -Martin AbstractUndoRecord #() SophieAddContentRootRecord #('contentRoot' 'book') SophieAddDeleteStickyRecord #('sticky' 'page') SophieAddStickyRecord #() SophieDeleteStickyRecord #() SophieAddEmbedBookRecord #('book' 'bookToEmbed') SophieAddLeafNodeRecord #('book' 'leafNode' 'contentIndexPosition') SophieAddStickiesRecord #('stickies' 'book') SophieApplyFrameLocationStyleAttributesRecord #('bookModel' 'anchor' 'styleAttributes' 'oldStyleAttributes' 'page') SophieApplyPageTemplateRecord #('page' 'template' 'undoData' 'redoData' 'allRemovedFrames') SophieApplyParagraphStyleAttributesRecord #('book' 'marker' 'styleAttributes' 'oldStylesAttributes') SophieApplyParagraphStyleRecord #('book' 'marker' 'style' 'oldStyles') SophieApplyStyleToRangeRecord #('book' 'marker' 'styleAttributes' 'oldRangesStylesCollection') SophieBookExtentUndoRecord #('bookModel' 'newExtent' 'oldExtent') SophieBookStatisticRecord #('book' 'newStatistic' 'oldStatistic') SophieDeleteContentRangeRecord #('book' 'marker' 'positionAfter' 'partialTree') SophieEmbeddedBookUndoRecord #('ebook' 'embeddedBookResource' 'embeddedBookMapEntry') SophieEmbeddedLinkedToBookUndoRecord #('ebook' 'embeddedBookMapEntry' 'embeddedBookResource') SophieFrameRecord #('bookModel' 'frame') SophieFrameZOrderRecord #('page' 'forward') SophieFrameStyleUndoRecord #('bookModel' 'frame' 'attributes' 'state') SophieFrameToTemplateRecord #('bookModel' 'frame' 'page' 'zIndex' 'reversed') SophieInsertCharacterRecord #('book' 'character' 'position' 'positionAfter' 'style') SophieInsertPageBreakRecord #('book' 'position' 'marker') SophieInsertParagraphBreakRecord #('book' 'position' 'marker' 'characterStyle') SophieLinkActionRecord #('book' 'target' 'action' 'actionIndex') SophieLinkActionAddRecord #() SophieLinkActionRemoveRecord #() SophieLinkRecord #('book' 'target') SophieFrameTriggerCleanupRecord #('cleanupStuff') SophieLinkActionCloneRecord #('source' 'oldActions') SophieMarkerAddDeleteRecord #('marker' 'book') SophieMarkerAddMarkersRecord #() SophieMarkerAddRecord #() SophieMarkerDeleteRecord #('actions' 'markerSet') SophieMarkerRangeRecord #('book' 'marker' 'newStart' 'newStop' 'oldStart' 'oldStop') SophiePageRecord #('bookModel' 'page') SophieFlowOrderChangeRecord #('frame' 'index' 'flow') SophiePageStyleRecord #('styleAttributes') SophiePageUndoRecord #('spine' 'index' 'page') SophieInsertPageRecord #() SophieMovePageRecord #('oldIndex') SophiePasteFromImporterRecord #('book' 'importer' 'position' 'marker' 'partialTree') SophiePromoteTemplateOverridesRecord #('book' 'pageTemplateFrame' 'page' 'frameMap' 'deletedTemplateFrames' 'overrideFrames' 'templateFrameFramesFromOverideFrames' 'frameOverrides' 'frameStyleOverrides' 'frameActionsOverrides' 'oldTemplateFrameFrames' 'oldPageFlowMap' 'oldTemplateFlowMap' 'oldPageTemplate' 'newTemplateFrameFrames' 'newPageFlowMap' 'newPageTemplate' 'allRemovedFrames' 'removedOverrideFrameContents') SophieRegisterFlowRecord #('spine' 'flowID' 'content' 'contentID' 'flow') SophieRemoveContentRootRecord #('contentRoot' 'book') SophieRemoveFlowRecord #('spine' 'flow') SophieRemoveFrameRecord #('bookModel' 'page' 'frame' 'wasLocalOverride') SophieRemoveLeafNodeRecord #('book' 'leafNode' 'oldContentIndexPosition') SophieRemovePagesRecord #('spine' 'indices' 'pages') SophieReplaceLibraryTemplateRecord #('book' 'template' 'newTemplate') SophieReplaceTemplateRecord #('book' 'template' 'oldTemplateCopy' 'newTemplate') SophieResourceUndoRecord #('resources') SophieResourceDeleteRecord #('player') SophieResourceImportStreamRecord #('resourceManager' 'mimeType' 'stream') SophieResourceImportURIRecord #('resourceManager' 'uri') SophieResourceLinkToURIRecord #() SophieResourceStoreRecord #('book' 'object' 'metaKey') SophieSpineStateDeltaRecord #('book' 'spine' 'addedPages' 'removedPages') SophieSpineStateRecord #('book' 'spine' 'prevState' 'postState') SophieTimelineUndoRecord #('timelinePlayer') SophieTimelineUndoAbstractEventsRecord #('events') SophieTimelineUndoAddEventsRecord #() SophieTimelineUndoDeleteEventsRecord #() SophieTimelineUndoAddTimeline #('timeline' 'book') SophieTimelineUndoDeleteTimeline #() SophieTimelineUndoEventsMoveRecord #('undoData') SophieTriggerObjectCleanupRecord #('triggerObject' 'undoInformations') SophieUpdateLibraryStyleRecord #('book' 'newStyle' 'styleName' 'oldStyle') UndoRecord #('undoable' 'doMessage' 'undoMessage' 'description') SophieFrameUndoRecord #('bookModel' 'frame') SophieLibraryResourceUndoRecord #('bookModel') SophiePageInvalidationRecord #('bookModel' 'page') SophieFrameAlignmentUndoRecord #('groupFrame' 'framesAndOldPositions' 'framesAndNewPositions') SophieTriggerMarkerUndoRecord #('bookModel' 'marker') UndoRecordWithPostMessage #('postMessage') UndoRecordGroup #('description' 'subRecords') SophieFrameGroupUndoRecord #('frameGroup' 'bookModel') -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 13, 2010

[Pharo-project] Undo/Redo [was: Re: Object Buffer (implementation tryout)]

by Martin McClure

John M McIntosh wrote: [...] > > PS if anyone is interested the Undo/Redo Logic that Impara did for > Sophie was very well received, easy to use, and we could build a book > from scratch > then undo the entire creation, then redo it. This sounds complex, it > was. However the framework made it easy, one piece at a time... > Perhaps someone should harvest that since it *was* generic. Ooh, nice. A good undo/redo framework would be *so* *very* good to have. I'm afraid I can't be the one to harvest it, not anytime soon anyhow, but I hope someone picks it up. Regards, -Martin

Jan. 13, 2010

Re: [Pharo-project] Object Buffer (implementation tryout)

by John M McIntosh

I was trying to rework the clipboard logic last fall but I couldn't find any window users to test it. Things like supporting cut/copy/paste of graphics objects. But it also required FFI in Pharo and I don't think anyone reached a decision on that. If anyone would like to take that task on I"ll give them an image to work with... I'll note in Sophie we support the cut/copy/paste of complex objects (chunks of books). A matter of checking what the object was, either text or a complex object. PS if anyone is interested the Undo/Redo Logic that Impara did for Sophie was very well received, easy to use, and we could build a book from scratch then undo the entire creation, then redo it. This sounds complex, it was. However the framework made it easy, one piece at a time... Perhaps someone should harvest that since it *was* generic. On 2010-01-12, at 1:10 AM, CÃ©drick BÃ©ler wrote: > > Perhaps a unified clipboard would be nicer... objects or text (or, > potentially converible to host OS things...). > > yes that would be really great (copy name seems useless to me... better to have copy object and paste name eventually) ! > But I don't have the expertise to do it I guess. For now we have in the image: > > Clipboard > ExternalClipboard (from Sophie) > MacOSClipboard > SqueakClipboard (empty !) -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 13, 2010

Re: [Pharo-project] Object Buffer (implementation tryout)

by Alexandre Bergel

I tried it and it works. Tests are clean and easy to understand. Look okay to me. Alexandre On 12 Jan 2010, at 13:29, CÃ©drick BÃ©ler wrote: > ping :) > > See you later, > > 2010/1/12 Alexandre Bergel <alexandre(a)bergel.eu> > Ok, I am waiting for your ping then > > Alexandre > > On 12 Jan 2010, at 12:17, CÃ©drick BÃ©ler wrote: > > > > > Anyway, feel free to publish whatever changes you find necessary > > (especially tests :) . I'll do some too) > > > > > > I'm writting some right now... > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > CÃ©drick > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by Alexandre Bergel

Thanks for this historical point. Cheers, Alexandre On 12 Jan 2010, at 23:25, Levente Uzonyi wrote: > On Tue, 12 Jan 2010, StÃ©phane Ducasse wrote: > >> >> On Jan 12, 2010, at 1:20 PM, Lukas Renggli wrote: >> >>> - #copy is the normal copy operation. It should be used by default >>> and >>> never overridden. It calls #postCopy that can be overridden to have >>> class specific copy semantics. >>> >>> - #shallowCopy does a shallow copy. It should never be overridden >>> and >>> only be used if you want to get these very specific semantics. >>> >>> - #deepCopy does a deep copy. It should never be overridden and only >>> be used if you want to get these very specific semantics. >>> >>> - #clone comes from eToys and Morphic (AFAIK). It implements some >>> other copy semantics than #copy. I don't think that anybody should >>> call this method, other than code that depends on this particular >>> copy >>> behavior. >> >> we should copy that in Object class comment and all the methods >> >> >> where do you see that it is morphic related for me clone is only >> implemented >> on character, Boolean, Object, SMalltInt symbol, UndefinedObject > > Back in the old days, Squeak 1.1 didn't have primitive 148 (which is > now used by both #shallowCopy and #clone). #shallowCopy was the way > to create a "one-level copy" of an Object. It had the same code as > today, but with no primitive. > Primitive 148 was introduced somewhere between 1.1 and 1.19 (note > that 1.2 came after 1.19). 1.19 (and probably earlier versions, but > not 1.1) had #clone which was primitive only and #shallowCopy which > didn't use the primitive. Morphic was being ported to Squeak at the > time and it was the only user of #clone. Morphs were copied by > #clone which was pretty fast, while other objects used #shallowCopy. > Later the use of #clone started to spread, until primitive 148 was > added to #shallowCopy. Sends of #clone were replaced with > #shallowCopy and #copy, but #clone was kept, probably for backwards > compatibility. > > #clone and #shallowCopy have a difference in their semantics. If the > vm cannot allocate enough space for the new object, #clone raises an > error immediately, while #shallowCopy signals the low space > semaphore, so the image or the user can do something, then retries > the copying. > > > Levente > >> >>> >>> This is exactly the same problematic as with #=. There can't be just >>> one #=. Other clients might consider other things when comparing >>> objects. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by Levente Uzonyi

On Tue, 12 Jan 2010, StÃ©phane Ducasse wrote: > > On Jan 12, 2010, at 1:20 PM, Lukas Renggli wrote: > >> - #copy is the normal copy operation. It should be used by default and >> never overridden. It calls #postCopy that can be overridden to have >> class specific copy semantics. >> >> - #shallowCopy does a shallow copy. It should never be overridden and >> only be used if you want to get these very specific semantics. >> >> - #deepCopy does a deep copy. It should never be overridden and only >> be used if you want to get these very specific semantics. >> >> - #clone comes from eToys and Morphic (AFAIK). It implements some >> other copy semantics than #copy. I don't think that anybody should >> call this method, other than code that depends on this particular copy >> behavior. > > we should copy that in Object class comment and all the methods > > > where do you see that it is morphic related for me clone is only implemented > on character, Boolean, Object, SMalltInt symbol, UndefinedObject Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility. #clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying. Levente > >> >> This is exactly the same problematic as with #=. There can't be just >> one #=. Other clients might consider other things when comparing >> objects. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 13, 2010

Re: [Pharo-project] [ANN] WorkingSet

by Romain Robbes

On Jan 12, 2010, at 5:59 PM, Simon Denier wrote: > > Yes! Many thanks Romain, I wanted something like that for the past 6 months (cf ESUG'09 ;)) > > It's good to see that now, dev tools are also starting to move. > > Two remarks: > - it seems like it replaces a bit Algernon in its features and user interaction. Am I right? Is this intended? hum ... I didn't try Algernon, actually. What I know is that it replaces my antique "Teleporter", which was included in BrowserBooster. > - do you plan to have multiple working sets (only one being active at any time)? This would allow one for switching between different contexts/projects while working in a image, and perhaps even sharing with other users (a bit like Mylyn) Yes, that would be nice. It's on the radar :-) > Future work: integration in the browser :) > How do you envision that? I tried to not be too browser-specific, as these things are moving targets. Romain > > > On 11 janv. 2010, at 16:42, Romain Robbes wrote: > >> Dear list, >> >> I've been working on a small tool to help people navigate their code in Pharo. >> WorkingSet tracks the entities you've changed recently, and lets you access them quickly. >> >> Load WorkingSet with: >> Gofer new >> squeaksource: 'WorkingSet'; >> package: 'WorkingSet'; >> load. >> >> Once loaded, press CMD-1 to activate or dismiss it. A User interface pops up, with the following key mappings: >> -H to get this help message. >> -1-9 to select a recently changed class or method (depending on which list is highlighted). >> -TAB to select methods, or the text field. >> -Left/Right arrow keys to select classes, methods, or text field. >> -Up/Down arrow keys to select an item in the list of classes or methods. >> -ENTER in the text field to navigate to the entity you typed. >> -ENTER or SPACE in a class or method list to select the selected item. >> -U to browse the users of an entity (methods: senders, classes: references). >> -S to browse the siblings of an entity (methods: implementors, classes: hierarchy). >> -K to close all windows opened by WorkingSet. >> -L & R to shift the WorkingSet window left or right. (in case you use several screens). >> -ESC or CMD-1 to dismiss WorkingSet. >> >> The text field allows you to enter classes and methods which are not present in your working >> set. You can enter multiple classes/methods at once by separating them with spaces. >> >> Enjoy! >> Romain >> -- >> Romain Robbes >> http://www.inf.unisi.ch/phd/robbes >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://www.inf.unisi.ch/phd/robbes

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by Levente Uzonyi

On Tue, 12 Jan 2010, StÃ©phane Ducasse wrote: > http://code.google.com/p/pharo/issues/list?thanks=1789 > > I do not understand why we need deepCopy and why deepCopy does not implement the veryDeepCopy semantics? Because it's lightweight compared to #veryDeepCopy. Levente > > On Jan 12, 2010, at 1:41 PM, Levente Uzonyi wrote: > >>> - #copy is the normal copy operation. It should be used by default and >>> never overridden. It calls #postCopy that can be overridden to have >>> class specific copy semantics. >>> >>> - #shallowCopy does a shallow copy. It should never be overridden and >>> only be used if you want to get these very specific semantics. >>> >>> - #deepCopy does a deep copy. It should never be overridden and only >>> be used if you want to get these very specific semantics. >> >> It doesn't handle cycles, #veryDeepCopy does. >> >>> >>> - #clone comes from eToys and Morphic (AFAIK). It implements some >>> other copy semantics than #copy. I don't think that anybody should >>> call this method, other than code that depends on this particular copy >>> behavior. >>> >> >> From Morphic. >> >> >> Levente >> >>> This is exactly the same problematic as with #=. There can't be just >>> one #=. Other clients might consider other things when comparing >>> objects. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 13, 2010

Re: [Pharo-project] EventSensor vs EventInputSensor

by Schwab,Wilhelm K

I did essentially what you propose early on to get things to shut up as I filed in a lot of my code from Dolphin, and I suffered for it later. What I wish I had done was add classes as subclasses of things already in the image. Of course, if you add EventSensor under InputEventSensor, you will likely find that the system will go right on using InputEventSensor, with the methods added to the (non-instantiated) subclass. I ran into weird behavior that I never fully understood, but undoing my system dictionary games got me out of it. The changes I made ended up being bootstrapping tricks that are better done by using regular expressions and match/replace to edit the SIF files. Back up first, and give it a shot. Good luck! Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Miguel Enrique CobÃ¡ Martinez Sent: Tuesday, January 12, 2010 7:25 PM To: Pharo Subject: [Pharo-project] EventSensor vs EventInputSensor I have a question about EventSensor. In Pharo doesn't exists anymore, it was replaced by InputEventSensor that has this class comment: An InputEventSensor is a replacement for the old Morphic EventSensor framework. It updates its state when events are received so that all state based users of Sensor (e.g., Sensor keyboard, Sensor leftShiftDown, Sensor mouseButtons) will work exactly as before. The usage of these funtions is discouraged. I am installing Magma on a Pharo core image and Magma uses EventSensor, by adding some methods to this class. As the class doesn't exist it shows the following message: This package depends on the following classes: EventSensor You must resolve these dependencies before you will be able to load these definitions: EventSensor classSide>>maMaterializeFromGraph:using: EventSensor>>maAsStorageObject EventSensor>>maUsesStandardStorage Select Proceed to continue, or close this window to cancel the operation. If before loading Magma I do Smalltalk at: #EventSensor put: InputEventSensor. Then everything works without warnings. Also the InputEventSensor receives the methods added by Magma. My questions are: Is this valid? Must this (the InputEventSensor in the slot of EventSensor in Smalltalk) be part of the image or will be a regresion to the situation before the deletion of EventSensor? What will be the correct way to handle this, change the Pharo/PharoCore with my hack or to ask Chris Muller, the maintainer of Magma to not use EventSensor but InputEvenSensor in the case of Pharo/PharoCore? Can I be reminded of the reasons to drop EventSensor in favor of InputEvenSensor? Thanks for the answers -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

[Pharo-project] MC case sensitity and sub-packages

by Schwab,Wilhelm K

Brian and others have told me that I could expect to define packages such as DolphinCompatibility-ODBC DolphinCompatibility-Streams and save them all using DolphinCompatibility, or save just one specific part by giving the full name, such as DolphinCompatibility-ODBC. I was unable to make it work reliably, and I think I might have just figured out why. Assertion: package names and class names must agree up to case; method categories (*packageName-etc) appear to be more forgiving. It further appears that once one messes up by naming a category and package Dolphincompatibility instead of DolphinCompatibility, the only way to fix it is to delete the working copy of the package and re-create it with the correct case after renaming the category, or something like that. Does that sound right? Am I missing something that might cost me later? Bill

Jan. 13, 2010