--- Begin Message ---
Op 26-4-2020 om 06:30 schreef Richard O'Keefe:
Roelof, *I* was offering to write something.
On Sat, 25 Apr 2020 at 19:47, Roelof Wobben via Pharo-users
<pharo-users@lists.pharo.org> wrote:
Op 25-4-2020 om 08:30 schreef Richard Sargent:
On Fri, Apr 24, 2020, 22:25 Richard O'Keefe <rao...@gmail.com> wrote:
Roelof, I don't think CRC cards or the GRASP patterns or anything like that
addresses your immediate needs. Based on other questions of yours it
seems to me that your problem is not *organising* the responsibilities in an
OO program, but decomposing a problem into responsibilities in the first
place. I think this is perhaps the most important part of programming, and
the hardest to learn, not least because very few of us are good at teaching
it. We're not very good at teaching it in mathematics either. I do not think
your issues are anything to do with Pharo, Smalltalk, OOP, or programming
as such.
One symptom of the general problem that I've noticed is that I see code as
a very fluid sort of thing where pieces can be moved around and recombined,
while many people think of code as something solid and rather brittle.
I was thinking of writing up a short description of what I was thinking for a
RosettaCode example anyway. Would that help?
Thank you, Richard. I appreciate your offering this. I am not a teacher, so
your help is truly appreciated!
Moment, I have to look if I understand you right.
I think you have some strong points but the last one I did not understand well.
Do I have to write for example for a exercism challenge a short description
of that problem like people do with rosetta code challenges and example code ?
Roelof
oke, I also accept this offer also.
The more angles I learn to solve this , the more I can use that in later
challenges.
and if I understand everything right , the solution is very simple
linksTowards: anAddress do: aBlock
"Simple flood algorithm: route via all outgoing links.
However, just loopback if the receiver node is the routing destination."
address = anAddress
ifTrue: [ aBlock evaluate: loopback ]
ifFalse: [ outgoingLinks do: aBlock ]
and the flow is this :
send: aPacket
"Send aPacket, leaving the responsibility of routing to the node."
self
linksTowards: aPacket destinationAddress
do: [ :link | self send: aPacket via: link ]
so for linkTwowards the anAddress is the `aPacket destinationAdress `
and the aBlock is ` [:link | self send: aPacket via: link `
so if the address is the loopback one it would be ` self send: aPacket
via: loopback `
and send is this :
send: aPacket via: aLink
aLink emit: aPacket
so that would be ` loopback emit : aPackage `
and that would lead to :
emit: aPacket
"Packets are not transmitted right away, but stored.
Transmission is explicitly triggered later, by sending #transmit:."
packetsToTransmit add: aPacket
where packetsToTransmit is a OrderedCollection
where the packet is added
Waiting till the transmit method is called where the sending of a
package is simulated.
Roelof
--- End Message ---
