73 lines
2.3 KiB
Plaintext
73 lines
2.3 KiB
Plaintext
From: fredrik at pythonware.com (Fredrik Lundh)
|
|
Date: Thu, 15 Apr 1999 14:56:29 GMT
|
|
Subject: Different methods with same name but different signature?
|
|
References: <3716909C.D8D1B372@fedex.com> <005201be8748$51e0bab0$f29b12c2@pythonware.com> <3715f36d.74192342@news.oh.verio.com>
|
|
Message-ID: <002901be8750$2727dd50$f29b12c2@pythonware.com>
|
|
Content-Length: 1968
|
|
X-UID: 422
|
|
|
|
Kevin Dahlhausen wrote:
|
|
> >imho, it's also an improvement over the pure visitor pattern,
|
|
> >since it allows you to generate "logical events" that doesn't
|
|
> >correspond to "physical" data instances in your model.
|
|
>
|
|
> I don't quite follow you. Can you explain this in a more detail?
|
|
|
|
here's an example from my upcoming Python book:
|
|
|
|
one chapter deals with a simple 2D animation system. its
|
|
animation subsystem generates Movie object, which has a
|
|
list of Frame objects, each of which contain a list of Sprite
|
|
objects.
|
|
|
|
this representation can be rendered to a display, to vector
|
|
graphic file formats, or to raster images (e.g. GIF animations,
|
|
or "ARG" files). the rendering machinery is implemented via
|
|
visitors, using the following interface:
|
|
|
|
class Renderer(MovieRenderer):
|
|
def movie_start(self, movie)
|
|
# called before any subframes
|
|
def movie_end(self, movie)
|
|
# called after all subframes
|
|
def frame_start(self, frame)
|
|
# called for each new Frame, before
|
|
# any shapes are visited
|
|
def frame_end(self, frame)
|
|
# called for each Frame, after all
|
|
# shapes
|
|
def sprite(self, sprite)
|
|
# called for each Sprite
|
|
|
|
the render implementations need to do things both before
|
|
and after each Frame (e.g. blank the image memory for each
|
|
new Frame, and flush the result to disk afterwards).
|
|
|
|
the Movie, Frame, and Sprite classes have methods looking
|
|
something like:
|
|
|
|
class Frame:
|
|
...
|
|
def accept(self, visitor):
|
|
visitor.frame_start(self)
|
|
for sprite in self.sprites:
|
|
sprite.accept(visitor)
|
|
visitor.frame_end(self)
|
|
|
|
etc.
|
|
|
|
makes sense?
|
|
|
|
anyone got a better solution? (but be warned that code that includes
|
|
apply(self.__do[tuple(map(type, args))], (self,) + args) (*) or similar stuff
|
|
is automatically disqualified ;-)
|
|
|
|
</F>
|
|
|
|
*) taken from an old post of mine... what was I thinking...
|
|
|
|
|
|
|
|
|
|
|