Sophie,
Yes, yes. I am currently coding with roles as pragmas as in this method: /stepArrows <Role: #ArrowtrainHead> ArrowtrainHead isFinished ifTrue: [... currentState := #FLASHSTAR] ifFalse: [ArrowtrainHead smallStep] /where inline code binds role names to application objects through a collaboration dictionary that lives on the stack. (Through a small extension of the compiler).
My next step is to code the methods as Traits, thereby further loosening the binding between role and object/class. I didn't mention the non-class structures earlier because their usage is somewhat immature for squeak-like programs. All the behavior part of UML 2.x should be worth looking at for modeling Squeak processes.
Cheers --Trygve
On 19.02.2008 16:04, itsme213 wrote:
"Trygve Reenskaug" trygver@ifi.uio.no wrote in message
The most important phenomena occur in the space between the objects, so I don't think method annotations would help (since they apply to one method at the time).
Like a collaboration? Could one use: A>>m1 <collab: #c1 role: #r1> <collab: #c2 role: #r1> A>>m2 <collab: #c2 role: #r2> B>>m3 <collab: #c1 role: #r3>
Could be done in Traits as well.
Thanks for sharing your insights. I was expecting the newer (non-class) structure diagrams to be on your list :-)
Sophie