Re: [ANN] HOM paper available
Re: [ANN] HOM paper available
- Subject: Re: [ANN] HOM paper available
- From: T Reaves <email@hidden>
- Date: Fri, 9 Sep 2005 09:04:11 -0500
On Sep 9, 2005, at 6:44 AM, Marcel Weiher wrote:
On 6 Sep 2005, at 23:34, John C. Randolph wrote:
On Sep 6, 2005, at 12:47 AM, Marcel Weiher wrote:
the draft of a paper on Higher Order Messaging has now been made
available at http://www.metaobject.com/
Very cool stuff! I especially like the -ifResponds HOM. When did
you come up with that?
Thanks, John! :-)
I have to admit, I can't remember when I came up with that. I
think I actually implemented it for the paper, because I wanted a
really concise example. Iteration doesn't work that well because
the implementation is significantly more bulky, which also
reinforces the misconception that HOM is an iteration mechanism.
Which it isn't. It's a mechanism/method for building things like
iteration mechanisms.
On the other hand, it had been running around in my head for quite
some time. Whenever I see patterns like that nowadays, I see an
opportunity for another little HOM.
Cheers,
Marcel
HOM are nice; I've always thought the way Smalltalk set up a lot
of the messages seemed more natural that the way Java does, and to a
lesser extent Obj-C. But HOM isn't a 'better way of doing things.'
It's a way of doing things that in certain circumstances has
advantages. It's easy to fall into the trap common to a lot of new
ideas, at that is: 'this is a great way of doing things and all
things should be done this way.' In other words, just because
something could be accomplished with HOM, does no imply it should be.
A - perhaps over simple - example of this is the example from
the mentioned paper dealing with add all of one persons direct
reports to another persons direct reports. In that example, the
author showed how to do it with HOM; but it should never actually be
coded that way. It was more difficult to understand than a more
traditionally coded means of accomplishing the task. Perhaps a
hybrid of HOM and traditional messages would have solved the issue
more gracefully.
I've known a lot of Perl developers over the years that felt
Perl was far superior to other languages because the HOM it provides
allowed for a solution to a problem with a lot less code being
written than would be required in other languages with their more
verbose method/message structure. Whereas the reduced amount of code
is true, that does not imply that it is a better solution. Perl is a
very difficult language to maintain an application in, because it is
so terse.
Another potential issue is the select: example from Smalltalk.
The author correctly points out that the developer must inject via a
block closure that functionality required to specify the elements of
interest. However, as with much code, there is no reason to abstract
that logic out until there is a need to. If it is a one-off
criteria, it is most appropriately defined where it is needed. Once
it is needed more than once, I'd then look to refactor that criteria
into some other higher level object.
I'm all for making code easier to understand, and more
expressible as relates to the way we developers think about
algorithms. I'm just trying to point out that HOM - as the author of
the paper lays it out - is valuable, but just like any other tool, is
subject to misuse and religious verve.
Hopefully we'll see some of those ideas rolled up into future
Obj-C libraries!
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden