I need a message-goto object language
Paul Dufresne
ace910@agora.ulaval.ca
Sun, 23 Jul 2000 20:35:36 -0400
Hi, I'd like to share a problem I am having. This is not directly about
Tunes, but I guess it is better
to post here than on OS-Ideas since the traffic is so low by now, that
it will just wake you up.
I use to be a bad programmer that directly go and program on the
computer rather than thinking on paper
before going on the computer. But this time, I decided to spend some
times on paper. I usually avoid flowcharts prefering to use pseudo-code.
Flowcharts ('ordinogramme' in french) often give some nice paper results
that is not so easy to
transform in while and for without using any goto. The obvious way to
program this kind of flowchart is to
just not doing any while, repeat or for and just use ifs and gotos. But
this time, I began writing some
kind of flowchart. Not exactly traditional one. I just make some kind of
data-flow diagram. Each box
have some inputs arrows (in my mind incoming messages), and output
arrows (outgoing messages).
In my mind, arrows was the data-flow of the program, so data-flow can
enter by any arrows, and must
get out by one outgoing arrows. Inside a box, there are others boxes.
Well, on paper it does not look too
much spaghetti, like we use to call this kind of goto-message
programming, because the program is
structured in a systemic way (boxs in boxs).
But now it seems hard to program in a true programming language, because
normally, calling a method
suppose that the data-flow will come back, and I did not make this
assertion in doing my flowcharts.
To allow a return value, I just create an other ingoing arrow at my box,
and the box I send a message can
send a value to the previously mentionned ingoing arrow, but it is not
mandatory like in all programming
languages I seems to know. How am I suppose to transform my flowchart to
program it. Or maybe I would
have to create a new object-oriented language that do message-goto
rather than message-calling.n :-)
I hope I made myself clear enough to be understood.
--Paul Dufresne