Switsch Statement like in java.Matej Košík kosik at fiit.stuba.skFri Sep 16 10:31:24 UTC 2005
Hilaire Fernandes wrote: > Hello, > > In the book "Squeak by examples" > (http://www.iam.unibe.ch/~ducasse/FreeBooks.html) , there is a chapter > dedicated to procedural to OO programming > http://www.iam.unibe.ch/~ducasse/FreeBooks/ByExample/30%20-%20Chapter%2028%20-%20Eliminating%20Procedural.pdf I have added a note distributed TODO list: http://altair.dcs.elf.stuba.sk/wiki/Kosik/COND#PossibleEnhancements Currently, there are only two cond:cond:... invocation in the project where I am using it. Both are in the same (horrible-but-now-I-do-not-know-how-to-make-it-prettier-but-now-it-really-does-not-matter) method. Its source code is: --------------------------------------------------------------------- createFieldFrom: aSystem "The purpose of this method is explained in its sender." "This method works in following phases 1. We go through all the objects living in the system (activated as well as passive). 1. We make copy of their mailbox to which they are listening. 2. We add newly created copy to this virtual-machine-state-copy. 3. We add an association mapping the original mailbox/mail/slit to their corresponding copies. These associations are held by the `mapping' dictionary. This dictionary is a return value of this method. It is used in the second phase of the virtual-machine-state-copying-procedure. 4. All the futures (THEY CANNOT BE PRESENTS, i.e. no object could listen to them), to which particular mails refer, are collected in a `futures' set for further processing. These should be also processed. 2. We go through the `futures' collection (we copy it) unless it was already copied (IT SHOULD NOT). This is a recursive procedure which removes the first future from the `futures' collection copies all its elements and 1. updates the `mapping' dictionary 2. updates the `futures' set and so on until the `futures' set is empty (all the futures in the system were already copied and registered in the `mapping' dictionary). We go through the set of all futures again and add a left caption to them indicating their id. 3. We go through the set of all objects again and update the left captions of all the MailboxCopy-ies to catch the information about which present mailbox belongs to what kind of object - prototype - integer - copy of a prototype That is, we try to conceive reasonable name for all present mailboxes. 5. We go through the set of all attributes of all object and update the left caption of all the MailboxCopy-ies to catch the information about: which attribute of what object refers to what mailbox. Here we use those reasonable names of the objects we have conceived in the previous (3-rd) phase. Here we also do the same for the indexed-attributes of particular objects." | mapping futures alreadyProcessedFutures | mapping _ Dictionary new. futures _ Set new. alreadyProcessedFutures _ Set new. "1-st phase ..." aSystem objects do: [:object | | mailbox mailboxCopy | mailbox _ object mailbox. mailboxCopy _ MailboxCopy id: mailbox id forcedRenderingOfPreviousStateOfAnAttributeSetToDifferentValue: mailbox forcedRenderingOfPreviousStateOfAnAttributeSetToDifferentValue forcedRenderingOfCurrentStateDuringPrimitiveOperation: mailbox forcedRenderingOfCurrentStateDuringPrimitiveOperation forcedRenderingOfNextStateAfterPrimitiveOperation: mailbox forcedRenderingOfNextStateAfterPrimitiveOperation isPresent: true. mailboxCopies add: mailboxCopy. mapping at: mailbox put: mailboxCopy. mailbox items do: [:mailboxItem | mailboxItem mailboxCopy: mailboxCopy mapping: mapping futures: futures alreadyProcessedFutures: alreadyProcessedFutures ] ]. "2-nd phase ..." [futures isEmpty] whileFalse: [ | future futureMailboxCopy | future _ futures anyOne. futures remove: future. alreadyProcessedFutures add: future. futureMailboxCopy _ MailboxCopy id: future id forcedRenderingOfPreviousStateOfAnAttributeSetToDifferentValue: future forcedRenderingOfPreviousStateOfAnAttributeSetToDifferentValue forcedRenderingOfCurrentStateDuringPrimitiveOperation: future forcedRenderingOfCurrentStateDuringPrimitiveOperation forcedRenderingOfNextStateAfterPrimitiveOperation: future forcedRenderingOfNextStateAfterPrimitiveOperation isPresent: false. futureMailboxCopy addLeftCaption: future id asString. mailboxCopies add: futureMailboxCopy. mapping at: future put: futureMailboxCopy. future items do: [:mailboxItem | mailboxItem mailboxCopy: futureMailboxCopy mapping: mapping futures: futures alreadyProcessedFutures: alreadyProcessedFutures ] ]. "3-rd phase ..." aSystem objects do: [:object | "Is a given object a prototype? That, is it registered in the `actorTraits'? NOTE: `associations' is a sub-dictionary of the `aSystem actorTraits named...'." | mailboxCopy associations methodParentSlots | mailboxCopy _ mapping at: object mailbox. associations _ aSystem actorTraits namedAttributeSlots select: [:association | association value listener == object]. methodParentSlots _ object methodParentSlots. [1 <= associations size] -> [ "Current object is registered in `objectTraits' at least once. Normally, it is registered there only once, but this branch handles also the situation when it is registered therein multiple times." associations associations do: [:association | | prototypeName mailbox | prototypeName _ association key. mailbox _ association value. [object == mailbox listener] assert. mailboxCopy addLeftCaption: prototypeName. ] ] "No. Current object is not a prototype. We will have to determine its ``name'' in some different way." "Is the current object `objectTraits'? This is special situation. It has no method parents but it is an important object because it has lot of attributes and thus this object should have proper name so when it appears in those mailboxes which are attributes of this object, it is clear which object refers them." cond: [object == aSystem actorTraits] -> [ "Yes. Current object is `actorTraits'" mailboxCopy addLeftCaption: 'actorTraits' ] "Does a given object have no method parent?" cond: [methodParentSlots size = 0] -> [ "Yes. Current object has no method parents. This is unusual, but theoretically it may happen. Also `actorTraits' has no method parents, although it is usually not sent a message directly." mailboxCopy addLeftCaption: '?:', object mailbox id asString ] "Does a given object have only one method parent?" cond: [methodParentSlots size = 1] -> [ "Yes. Current object has only one method parent. This is normal situation." | methodParentName | methodParentName _ methodParentSlots keys anyOne. "Is current object an integer?" [object isKindOf: IntegerActor] -> [ mailboxCopy addLeftCaption: '#', object value asString, ':', object mailbox id asString ] "Is it a context?" cond: [object isKindOf: ContextActor] -> [ mailboxCopy addLeftCaption: object formalBlockAcceptor printStringAsLine, ':', object mailbox id asString ] "Is current object copy of the Workspace prototype?" cond: [methodParentName = 'actorTraitsOfWorkspace'] -> [ mailboxCopy addLeftCaption: 'workspace:' ] cond: [methodParentName = 'actorTraitsOfMagnitude'] -> [ mailboxCopy addLeftCaption: 'magnitudeTraits:' ] cond: [methodParentName = 'actorTraitsOfNumber'] -> [ mailboxCopy addLeftCaption: 'numberTraits:' ] cond: [methodParentName = 'actorTraitsOfPoint'] -> [ mailboxCopy addLeftCaption: 'pointTraits:' ] cond: [methodParentName = 'actorTraitsOfMatrix'] -> [ mailboxCopy addLeftCaption: 'matrixTraits:' ] cond: [methodParentName = 'actorTraitsOfContext'] -> [ mailboxCopy addLeftCaption: 'contextTraits:' ] cond: [methodParentName endsWith: 'Traits'] -> [ "We have an object, which is not of any destinct identity. Its name will be based upon the name of its method parent." "... remove the `Traits' suffix" mailboxCopy addLeftCaption: (methodParentName truncateTo: methodParentName size - 6), ':', object mailbox id asString ] otherwise: [ "This branch handles all the rest cases." mailboxCopy addLeftCaption: '?:', object mailbox id asString ] ] cond: [(methodParentSlots includesKey: 'magnitudeTraits') & (methodParentSlots includesKey: 'numberTraits')] -> [ mailboxCopy addLeftCaption: 'integerTraits:' ] otherwise: [ "Current object has more than one method parent." mailboxCopy addLeftCaption: '?:', object mailbox id asString ] ]. "5-th phase ..." "NOTE: We have simplified things, we disregard the attributes inherited from attribute parents. Those cases are not be visualizable (for now)." aSystem objects do: [:object | | objectCaption | "Artificially computed name for the currently processed object we have computed in the previous phases." objectCaption _ (mapping at: object mailbox) leftCaptions first. "Here we deal with named attributes." object namedAttributeSlots keysAndValuesDo: [:key :value | "key ... name of the attribute value ... the named attribute itself (a mailbox)" (mapping at: value) addLeftCaption: objectCaption, '/', key ]. "Here we deal with indexed attributes." object indexedAttributeSlots withIndexDo: [:value :index | "index ... current index of the indexed attribute value ... the indexed attribute itself (a mailbox)" (mapping at: value) addLeftCaption: objectCaption, '/', index asString ] ]. ^ mapping --------------------------------------------------------------------- Its purpose is to create a copy of my virtual machine state for later visualization. Those horrible cond:cond:cond:...otherwise: decide what caption should be attached to particular mailbox in order to give me some useful iniformation. As for example here http://altair.dcs.elf.stuba.sk/~kosik/tmp/Book4/page8.html (I am sorry, the picture is actually scrolled and simple-minded conversion a BookMorph to HTML does is in these cases useless) The captions "Workspace actorTraits/Workspace" ... I am a (present) mailbox to which `Workspace' object is listening. I am also the mailbox refered by actorTraits's Workspace slit. "#1:48" ... I am a (present) mailbox to which 1-integer actor is listening. Unique id of this mailbox (each to enable me to totally identify them when they are visualized) is 48. "46" ... I am a (future) mailbox whose id is 46 "55" ... I am a (future) mailbox whose id is 55 "62" ... I am a (future) mailbox whose id is 62 are descriptive which couldn't be generated solely by nice polymorphism technique because what should be done (what label should be attached to the particular mailbox) cannot be decided solely by the type. So, there is a single place where I officially use COND. It helps me to solve this ugly problem. > > > It is worth reading. I'll do that. The Visitor pattern suggested earlier was also quite interesting. > > Hilaire Fernandes > > Lic. Edgar J. De Cleene a écrit : > >> Michaël Piel puso en su mail : >> >> >>> Instead of #caseOf: and #caseOf:otherwise: use a dictionary. >>> >>> michael >> >> >> Could send to list a few lines example ? >> I used #caseOf: and #caseOf:otherwise until Matej send about COND. >> Likes learn more. >> >> Edgar >> >> >> >> >> >> >> >> ___________________________________________________________ 1GB >> gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del >> mundo http://correo.yahoo.com.ar >> > > Regards -- Matej Košík, ICQ: 300133844, http://altair.dcs.elf.stuba.sk/wiki/Kosik/Main
More information about the Squeak-dev mailing list |