[squeak-dev] The Trunk: EToys-tfel.253.mcz
Kjell Godo
squeaklist at gmail.com
Mon Sep 26 17:39:12 UTC 2016
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 <squeaklist at gmail.com> wrote:
> 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 <squeaklist at gmail.com
> <javascript:_e(%7B%7D,'cvml','squeaklist at gmail.com');>> wrote:
>
>> 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 <squeaklist at gmail.com> wrote:
>>
>>> M class>>doesNotUnderstand: aMessage ^aMessage asMessageSend !
>>>
>>> ( ( M som:eMe:ssa:ge: inputs ) receiver: obj )
>>>
>>> On Monday, September 26, 2016, Kjell Godo <squeaklist at gmail.com> wrote:
>>>
>>>> M>>doesNotUnderstand: aMessage ^aMessage asMessageSend !
>>>>
>>>> ( M handUserSorterMorphForProjectNamed: nil )"<---[ easy way to make a
>>>> MessageSend ]"
>>>> ...
>>>> sendTo: obj
>>>>
>>>> On Monday, September 26, 2016, <commits at source.squeak.org> wrote:
>>>>
>>>>> 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!
>>>>>
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160926/c912e63d/attachment-0001.htm
More information about the Squeak-dev
mailing list
|