Out: Monday, November 16, 2015
Due: Monday, November 30, 2015 at 600pm local time.
The goal of this problem set is to give you practice with stateful classes, and pulling and pushing information. It is also intended to give you practice with reusing code from previous problem sets.
Please restrict yourself to the language features discussed in class. You may use state. You may not use inheritance.
Otherwise, the deliverables and instructions for this problem set are the same as for Problem Set 09. As always, you must follow the design recipe, in this case the OO Design Recipe and deliverables as spelled out in Lesson 9.5 and in deliverables.html. Be sure to sync your work and fill out a Work Session Report at the end of every work session. Use the Work Session Report for PS 10.
Also, starting with this problem set, you may submit your solution in multiple files. See details below.
(define StatefulWorld<%> (interface () ; Widget<%> -> Void ; GIVEN: A widget ; EFFECT: add the given widget to the world add-widget ; SWidget -> Void ; GIVEN: A stateful widget ; EFFECT: add the given widget to the world add-stateful-widget ; PosReal -> Void ; GIVEN: a framerate, in secs/tick ; EFFECT: runs this world at the given framerate run )) ;; Every functional object that lives in the world must implement the ;; Widget<%> interface. (define Widget<%> (interface () ; -> Widget<%> ; GIVEN: no arguments ; RETURNS: the state of this object that should follow at the next tick. after-tick ; Integer Integer -> Widget<%> ; GIVEN: a location ; RETURNS: the state of this object that should follow the ; specified mouse event at the given location. after-button-down after-button-up after-drag ; KeyEvent : KeyEvent -> Widget ; GIVEN: a key event ; RETURNS: the state of this object that should follow the ; given key event after-key-event ; Scene -> Scene ; GIVEN: a scene ; RETURNS: a scene like the given one, but with this object ; painted on it. add-to-scene )) ;; Every stable (stateful) object that lives in the world must implement the ;; SWidget<%> interface. (define SWidget<%> (interface () ; -> Void ; GIVEN: no arguments ; EFFECT: updates this widget to the state it should have ; following a tick. after-tick ; Integer Integer -> Void ; GIVEN: an x and a y coordinate ; EFFECT: updates this widget to the state it should have ; following the specified mouse event at the given location. after-button-down after-button-up after-drag ; KeyEvent : KeyEvent -> Void ; GIVEN: a key event ; EFFECT: updates this widget to the state it should have ; following the given key event after-key-event ; Scene -> Scene ; GIVEN: a scene ; RETURNS: a scene like the given one, but with this object ; painted on it. add-to-scene )) ;; make-world : NonNegInt NonNegInt -> StatefulWorld<%> ;; GIVEN: the width and height of a canvas ;; RETURNS: a StatefulWorld object that will run on a canvas of the ;; given width and height.
You are relieved to see that these interfaces are much like the ones you've been working with. The difference is that you will run the objects by creating a StatefulWorld, adding your widgets to it, and then calling the run method on your world. You no longer need to call big-bang yourself.
Your job is to reimplement the toy from problem set 9, but using the WidgetWorks framework and stateful objects. The specifications are exactly the same, except that:
Turn in your solution as a file named "toys.rkt". Put a copy of WidgetWorks.rkt in the directory with your solution. YOU MAY NOT MODIFY WidgetWorks.rkt IN ANY WAY. WE MAY TEST YOUR SOLUTION WITH OUR OWN IMPLEMENTATION OF StatefulWorld<%>.
Here's a demonstration:
Your solution should be a file named cubelets.rkt that provides the following functions:
make-playground : -> PlaygroundState GIVEN: no arguments RETURNS: a PlaygroundState make-block : NonNegInt NonNegInt ListOfBlock<%> -> Block<%> GIVEN: an x and y position, and a list of blocks WHERE: the list of blocks is the list of blocks already on the playground. RETURNS: a new block, at the given position, with no teammates NOTE: it is up to you as to whether you use the third argument or not. Some implementations may use the third argument; others may not. The Block<%> interface extends the SWidget<%> interface with AT LEAST the following methods: get-team : -> ListOfBlock<%> RETURNS: the teammates of this block add-teammate: Block<%> -> Void EFFECT: adds the given block to this block's team block-x : -> Integer block-y : -> Integer RETURNS: the x or y coordinates of this block
You may put more methods in the Block<%> interface if you so desire. Remember that a method must appear in the interface if and only if it is called from outside this object.
There are several places where information must be disseminated in this problem, either by pushing or pulling. Be prepared to identify these and to discuss your design decisions about each of them.
As in the problem above, you must use WidgetWorks.rkt .
Last modified: Thu Dec 3 15:03:04 Eastern Standard Time 2015