Tim Felgentreff uploaded a new version of EToys to project The Trunk:
http://source.squeak.org/trunk/EToys-tfel.253.mcz ==================== Summary ==================== Name: EToys-tfel.253 Author: tfel Time: 26 September 2016, 11:40:48.856552 am UUID: a00694aa-7017-b444-a8d0-6671ec171efd Ancestors: EToys-tfel.252 delete the project saving morph before saving =============== Diff against EToys-tfel.252 =============== Item was changed: ----- Method: EToyProjectDetailsMorph>>doOK (in category 'utilities') ----- doOK "User hit the ok button in the project-info dialog. Store the updated project-info back in the project. Call the message-send residing in the receiver's actionBlock to carry out any subsequent desired task. Note that this method sets the 'arguments' of the message-send in the actionBlock" | args actionSelector | self validateTheProjectName ifFalse: [^false]. projectDetails := self copyOutDetails. theProject acceptProjectDetails: projectDetails. "Make sure project & world feel the changes" + + self delete. - actionBlock isMessageSend "new way -- hopefully all cases" ifTrue: "please excuse this ugly, non-modular code..." [actionSelector := actionBlock selector. args := (actionSelector = #handUserSorterMorphForProjectNamed:) ifTrue: [{theProject name}] ifFalse: [actionSelector numArgs = 0 ifTrue: [nil] ifFalse: [Array with: projectDetails]]. actionBlock arguments: args. actionBlock value] ifFalse: "Old way, with actionBlock actually a block of one argument. This should no longer occur." + [actionBlock value: projectDetails].! - [actionBlock value: projectDetails]. - - self delete! Item was changed: ----- Method: EToyProjectQueryMorph>>doOK (in category 'ok button hit') ----- doOK "User hit the ok button in the project-query dialog." | details | details := self copyOutDetails. + self delete. actionBlock isMessageSend "new way -- hopefully all cases" ifTrue: [actionBlock arguments: {details. actionBlock arguments second}. actionBlock value] ifFalse: "Old way, with actionBlock actually a block of one argument. This should no longer occur." + [actionBlock value: details].! - [actionBlock value: details]. - - self delete! |
M>>doesNotUnderstand: aMessage ^aMessage asMessageSend !
( M handUserSorterMorphForProjectNamed: nil )"<---[ easy way to make a MessageSend ]" ... sendTo: obj
On Monday, September 26, 2016, <[hidden email]> wrote: Tim Felgentreff uploaded a new version of EToys to project The Trunk: |
M class>>doesNotUnderstand: aMessage ^aMessage asMessageSend !
( ( M som:eMe:ssa:ge: inputs ) receiver: obj )
On Monday, September 26, 2016, Kjell Godo <[hidden email]> wrote: M>>doesNotUnderstand: aMessage ^aMessage asMessageSend ! |
When is a MessageSend better than a BlockClosure?
I would like to know. Because you can change it? You can look inside. What if the arguments were Blocks. You could easily make a tree of MessageSends ( ( M message1:( M message2: obj2 ) message1:( M message3: obj31 message3: obj32 ) ) receiverDeep:{ r1. r2. r3 }"<---[ left right top down traverse ]" ) valueDeep
On Monday, September 26, 2016, Kjell Godo <[hidden email]> wrote: M class>>doesNotUnderstand: aMessage ^aMessage asMessageSend ! |
it becomes like a programming language.
Could it be used to allow restricted user customization. Like a scripting language given some kind of hierarchical editor.
On Monday, September 26, 2016, Kjell Godo <[hidden email]> wrote: When is a MessageSend better than a BlockClosure? |
a tree View that knew about types( Classes )
could do it. A tree context popUp Menu or popUp tree view could show you the valid options for any input to any Message that you were building. perhaps when this tree like scripting editor comes up it could show a tree view of the various things you could do similar to Scratch. then when you choose something it automatically takes you through all the choices by traversing the Message tree and filling in all the Message arguments by the user picking from popUp tree views that dissapear once you pick and then the pick fills in a Message argument and the user keeps going to fill in all the other Message arguments and when every argument is filled in the user has a finished script which can be run or called from other scripts or the scripts could be Methods in a Class Hierarchy of some kind maybe it helps you think OOP by asking questions like in the Pharo Class comment template what do you want this thing to be able to do what body parts do you want this thing to have how will it speak to others how will it speak to suppliers how will it speak to customers how will it speak to enemies what are its responsibilities how will it speak to itself what things does it need to store inside etc and it could perform some demos to show the ideas and then the MessageSend could be converted to Smalltalk and compiled if speed was need you could have MMessageSendSequence >>do: >>do:do: >>do:do:do: >>do:do:do:do: etc to make a sequence of MessageSends you could have MLet>>define: listOfAssociations in: messageSendSequence MAssociation>>key:value: MList>>n: >>n:n: >>n:n:n: etc MMethod>>inClass:makeMethod_withInputs:into: <---[ creates a Method ] >>inAnimal:makeBehavior_withInputs:into: MLambda>>makeLambda_withInputs:into: <---[ creates a Lambda ( BlockClosure ) ] MClass>>makeClass_superClass:bodyParts: MAnimal>>makeAnimal_superAnimal:addedBodyParts: maybe if you switched from Class>>Method to Animal>>Behavior it would require a lot less Splaining to get newbies to think OOP in fact it would take no explaining at all people would just get it So Class>>Method = big slowdown in the adoption rate of OOP Shouldabeen Animal>>Behavior that wouldabeen the Finnish way to do it they got the phonetic spelling system -> no illiteracy ha ha easy SmalltalkV manual did Animal>>Behavior A simple name change might have put Smalltalk on top but then there was the speed thing the speed thing On Monday, September 26, 2016, Kjell Godo <[hidden email]> wrote: it becomes like a programming language. |
Free forum by Nabble | Edit this page |