SPUG: Unidentified Flying Objects

Fred Morris m3047 at inwa.net
Tue Jan 10 23:51:40 PST 2006


Thanks JD, Andrew, Jeff and Charles:


Who'd'a thunk it? So, by the criterion that it's been thought of before,
it's crazy, but I'm not. Thanks to all of you, and it's been an interesting
little excursion. I'll give some more detail about the actual app, because
it speaks to how crazy this is (or isn't).

There are a small handful of patterns for this (web-based) application, and
there are a small handful of base classes which all declare some standard
"make it go" method which might be called ->handle-request(), and this
method in turn invokes any number of methods in some predefined order which
carry out the request. The base class defines default implementations of
these methods and subclasses override them as needed (actually for one-offs
they just provide callbacks; I am not a purist).

One of these patterns looks like: web request stuff, parameter bomb
checking, validation, access checking, some template fiddling, major
lifting, some more template fiddling, and finally return it to the user. I
don't mean to oversimplify. Let's call this the "edit" pattern.

One of the (maybe the only) aberrational edit operations is to take
ownership. At that point after what would otherwise be access checking we
have by definition arrived at the same state of knowledge which we would
have had by passively checking information which had been supplied in the
request had we owned the object in the first place. In the web interface,
the user was provided with a (read only) screen with an "edit" button. In
the pattern, pretty much all of the heavy lifting from this point on, for
taking ownership, is a no-op. So: do we send back some JavaScript template
which immediately sends a more usual request to edit the object, or do we
erect some scaffolding on the server side to accomplish the same thing.. or
recognizing that we are where we want to be do we simply, somehow, turn one
kind of request into another? Who knew that was possible? Well, obviously I
didn't until maybe 48 hours ago.


I know how I'd do it in Java (is this the third unspoken question: to know
what rules one is breaking?), I'd have some sort of factory class managing
(mangling?) an "item" class and a machinery class (subclassing the
fabrication steps) which fabricated it. I'd swap the machinery out. (This
is the subjective exercise: by doing so did I change the whole factory, or
did I pick the item up and move it to a different line mid-fabrication?
Does it matter?) You can turn that inside out or sideways (like Cat's
Cradle) and accomplish the same thing.


JD wrote:
>You can do something similar in JavaScript and Smalltalk.
>You can change add or change a method on an object.
>Something similar to your example (in JavaScript):
>
>var ufo = new Bird();
>ufo.i_am_a();
>ufo.i_am_a = Plane.i_am_a;
>ufo.i_am_a();
>

Yah, this is the callback notion and of course this is the kind of thing
the one-offs (which don't achieve full incarnation as subclasses) do.. very
much like the example given. I suppose the existing implementation looks a
lot like the "factory" described above, except that the factory (and its
subclasses) are the machinery and there is no discrete item (it is embodied
in the properties of the "factory").

That JavaScript example looks like you're taking the function definition
(which is an object) and using it to replace a different one. Cool. This is
how we would have done it in C, too, with some sort of struct containing
the procedure pointers for the various state handlers. I liked it then, I
like it now. I like state engines. ;-) Changing the handlers mid-operation
is unconventional but hearkens to the concept of frames which is
encountered in expert systems.

I don't think this sort of problem is particularly new, I just don't think
that it occurs often enough to rise above idiom and idiosyncracy to the
kind of thing which a language goes out of its way to tackle (except,
apparently, Perl.. although I think it's arguable that it goes out of its
way to handle it).

I suppose the best question would be: why not simply overwrite the handlers
when you realize the situation has changed? I don't have a great answer for
that, other than if you've done something once why do it again?


Jeff Almeida wrote:
>Think about the classic textbook example for multiple inheritance: a
>flying boat
>is both a boat and an airplane.  But really, it doesn't act like both
>of them at the
>same time... this way, it's a boat when it's a boat and it's and
>airplane when it's
>an airplane.

That is a textbook example, and maybe that is what Andrew was also thinking
about. Actually Andrew doesn't say that, on re-reading. Now I'm confused.
Well this seems like a textbook example. There is something about
"academic" and "Perl" in the same sentence and I think he knows what I'm
talking about. So, because he wasn't thinking about it, he was thinking
about it... clear as mud?

I was really coming at this particular case from the essential realization
that there was a point where an object which I was considering to be one
thing was in fact another in all but name... and this name was what was
preventing it from carrying on with being what it was.


Charles DeRykus wrote:
>Beware re-blessers that forgot to clean their dirty laundry....

I have a name! :-) :-)

Good point. Anything in my particular universe is going to change into a
subclass of the same base class. The pattern is defined by the base class.
I don't actually have destructors, although if they were defined by the
base class my guess is that I'd be o.k.

I am inclined to go with this rather sublime hack, and to document the crap
out of it and erect some sort of cage around it so that things can only
transmogrify into subclasses of the same base class.





More information about the spug-list mailing list