yogsototh/elm
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Moved comment to beginning to contextualize the program and emphasize design choices.

Browse source
This commit is contained in:
evancz 2012-08-17 19:26:22 +02:00
parent d0da29f2a0
commit ee2805a992
1 changed files with 27 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

39
Examples/elm-js/Pong/Pong.elm
View file

@ -6,6 +6,32 @@ import Signal.Keyboard.Raw
import Signal.Window as Win
{-----------------------------------------------------------------------
This code neatly divides Pong into three major parts: modeling the
game, updating the game, and viewing the game. It may be helpful to
think of it as a more functional (i.e. less imperative) version of
the Model-View-Controller paradigm.
Hopefully this game also displays some of the strengths of Functional
Reactive Programming. By the end of this file we will have written an
entire GUI/game without any imperative code! No global mutable state,
no flipping pixels, no destructive updates. In fact, Elm disallows all
of these things at the language level. So good design and safe coding
practices are a requirement, not just self-inforced suggestions.
The following code is structured as follows:
1. Models of game inputs (clock-ticks and keyboard input) and the
game itself (paddles, ball, score, etc.)
2. A step function that updates the game based on the inputs
3. A display function that defines the user's view of the game
Let's get started!
-----------------------------------------------------------------------}
------------------------------------------------------------------------
------ Extracting timesteps from JavaScript ------
------------------------------------------------------------------------
@ -269,16 +295,3 @@ foreign export jsevent "finished"
-- And finally, we display the view of the game to the user: Pong in Elm!
main = view
-- Note that the structure of this game neatly divides Pong into three major
-- parts: modeling the game, updating the game, and viewing the game. It may
-- be helpful to think of it as a more functional (i.e. less imperative)
-- version of the Model-View-Controller paradigm.
-- Hopefully this game also displays some of the strengths of Functional
-- Reactive Programming. We have written an entire GUI/game without any
-- imperative code! No global mutable state, no flipping pixels, no
-- destructive updates. In fact, Elm disallows all of these things at the
-- language level. Thus, good design is a requirement, not just a self-inforced
-- suggestion.