Property-Invocation Programming
Pete Oliver-Krueger
I've put together a new philosophy on object-oriented programming, and
built an implementation of it in ColdFusion. I'm looking to introduce
the ideas to other like-minded object-oriented folks, and get some
feedback from experienced OO developers, to see if I'm totally crazy
or not. It's called Property-Invocation Programming, or "Pi
Programming" for short. Details can be found at http://www.millionmunkeys.net/PiMunkey/,
where one can also download the CFC implementation.
Regards,
Pete Oliver-Krueger
President, MillionMunkeys LLC
Sean Corfield
<pe...@millionmunkeys.net> wrote:
> ...to see if I'm totally crazy
In order to download this and review it, we need to provide you with
our name and email address and agree to a custom software license
agreement and a non-disclosure agreement??
How can we possibly even discuss it on a public list if we have to
sign an NDA to get access to it?? "Don't tell people who are not bound
by this agreement about what's inside the software."
Have you actually heard of Open Source Software?
So, yes, you're "totally crazy" - and that's without even looking at
the actual idea :)
> It's called Property-Invocation Programming, or "Pi
> Programming" for short. Details can be found at http://www.millionmunkeys.net/PiMunkey/
You're making up a name for a small subset of a more general
event-based programming model. You claim that "you don't have to
register any events" but addListener() and addFilter() are exactly
that: event registration points (especially since you can register a
handler for an event that doesn't match an actual property). I don't
think there's anything particularly novel about the idea at large and
I think the forced mapping of an event-based system onto essentially
fake get/set methods is a fairly warped way to go about event-based
programming.
Since the event registration is per-object and is explicit, any
application needing to create transient domain objects using this
machinery would have to explicitly register all the event handlers
every time an object is created. That would lead to lots of event
registration code scattered throughout the app or to factory objects
that then have to know about all of the event handling logic - both of
which create a terrible tangle of dependencies. AOP is designed to
handle this sort of stuff (and is specifically suited to the example
you give about adding an audit trail to an object). AOP operates at
the class level rather than the object level, removing the problems of
registering event handlers everywhere an object is created.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
Pete Oliver-Krueger
for that. I will get that fixed and post a new license without an
NDA.
Thanks for posting responses though to the documentation. I'll
respond to those separately.
Pete
Pete Oliver-Krueger
> You're making up a name for a small subset of a more general
> event-based programming model. You claim that "you don't have to
> register any events" but addListener() and addFilter() are exactly
> that: event registration points (especially since you can register a
> handler for an event that doesn't match an actual property). I don't
Actually I'm thinking that it's more of a superset of the concept.
When I think of how we implement an event in code, some data point
changes state, and then handlers are alerted of the change. An event
is really just the setting of a variable. What if we made the setting
of any variable an "event"? Then we wouldn't even need the concept of
an event. You can just fire any handler function anytime it's
corresponding variable is set (or retrieved).
The main issue I ran into was where there wasn't an event to listen
for, and I had no control over the object being watched, or I didn't
want to modify that code to add a new event.
Here is one example from extjs: With extjs I didn't want to modify the
original source code, because that made upgrading to new versions a
pain, since code might get wiped out, or the modifications would need
to be manually transfered to the new code base.
I wanted to update the data store, though, because I found that the
way extjs handled paging was, at times, inefficient and buggy, and
required the calling objects (like a paging toolbar) to know too much
about the internals of the data store. What I wanted to do instead
was just override the page handling. The original code didn't have a
function for setting the page number. It required the paging toolbar
to calculate out the index of the first record, then the index of the
last record, and pass those indexes to the store, for which the
toolbar then needed to how many records there were, what the page size
was, whether there was grouping of the records, etc. Way too much
dependency.
Had extjs used property-invocation, I could have added a listener for
a currentPage property (which didn't exist, avoiding any overlap with
existing code) and executed my paging code instead. Then the paging
toolbars would only need to send a page number to the existing store,
with my listener processing it. Much simpler, and much less coupled.
There's also a testing issue, where if you modify the original source
code, you might then have to run whole sections of the application
through regression testing. If I just want to execute some code
halfway through a process, adding a transparent listener for the right
property means I only need to execute the test scripts dealing with
the new functionality, not the test scripts for the object being
listened to. But, if I did have to do regression testing, I would
have a very high likelihood that the bug was in the new code, since
the original code was untouched.
> ...I think the forced mapping of an event-based system onto essentially
> programming.
that warped has its uses. :)
> Since the event registration is per-object and is explicit, any
> application needing to create transient domain objects using this
> machinery would have to explicitly register all the event handlers
> every time an object is created. That would lead to lots of event
> registration code scattered throughout the app or to factory objects
> that then have to know about all of the event handling logic - both of
> which create a terrible tangle of dependencies. AOP is designed to
> handle this sort of stuff (and is specifically suited to the example
> you give about adding an audit trail to an object). AOP operates at
> the class level rather than the object level, removing the problems of
> registering event handlers everywhere an object is created.
Thanks again for the feedback.
Pete
Sean Corfield
<pe...@millionmunkeys.net> wrote:
> When I think of how we implement an event in code, some data point
> changes state, and then handlers are alerted of the change. An event
> is really just the setting of a variable.
Not true. State changes in an application are not restricted to a
variable changing its value - that's too narrow a view.
> The main issue I ran into was where there wasn't an event to listen
> for, and I had no control over the object being watched, or I didn't
> want to modify that code to add a new event.
But your method doesn't let you watch arbitrary objects - they must be
PiComponent instances and therefore you are implicitly modifying "that
code" because you're forcing it to be an instance of your own data
type. AOP allows for arbitrary objects to be wrapped in logic that
could, for example, raise events on setters and getters which could,
in turn, be listened to independently of the object being observed
(which is the goal: to avoid coupling).
> Had extjs used property-invocation, I could have added a listener for
> a currentPage property (which didn't exist, avoiding any overlap with
> existing code) and executed my paging code instead.
See my comment above. You can apply this sort of event model to
existing code without modifying it directly. And you get something
more flexible.
> I'll read up more on AOP and compare.
Cool.