Stefan
you should pay attention to what is the receiver of a cascade because this is really the receive of the first message involved in the cascade. OrderedCollection new add: 35; add: 45; yourself this is anOrderedCollection and not OrderedCollection but you probably know that. Stef
No. Cascades are simply a syntactic sugar for binding to a temporary, so
expr message1; ...; messageN
is syntactic sugar for
| t | ... t := expr. t message1. ... t messageN.
The implementation simply creates an anonymous temporary on the stack and reads it using dup, effectively push expr, dup, send, dup, send, pop.
I obviously need to make sure that if I flatten them, that I order receivers and arguments correctly. Is there anything else that could hinder flattening?
(Ah, and I am happy to ignore reflection, thisContext, or exceptions.)
Here two examples: ---> original: testCascadedSends | assoc | assoc := Association key: #foo value: 0.
assoc value: (1 + 2); value: assoc value + 2; value: assoc value + 5.
self assert: 10 equals: assoc value.
testCascadedNotInSequence | assoc | assoc := Association key: #foo value: 0.
assoc value: (assoc value: 1; value: 2; yourself).
self assert: assoc equals: assoc value. <---
---> transformed: testCascadedSends | assoc t* | assoc := Association key: #foo value: 0.
assoc value: (1 + 2). t1 := assoc value. assoc value: t1 + 2. t2 := assoc value. assoc value: t2 + 5.
self assert: 10 equals: assoc value.
testCascadedNotInSequence | assoc t* | assoc := Association key: #foo value: 0.
assoc value: 1. assoc value: 2. t1 := yourself. assoc value: t1.
self assert: assoc equals: assoc value. <---
Thanks Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
-- best, Eliot