Re: [ANN] HOM paper available
Re: [ANN] HOM paper available
- Subject: Re: [ANN] HOM paper available
- From: Marcel Weiher <email@hidden>
- Date: Fri, 9 Sep 2005 18:22:36 +0100
On 9 Sep 2005, at 15:04, T Reaves wrote:
On Sep 9, 2005, at 6:44 AM, Marcel Weiher wrote:
On 6 Sep 2005, at 23:34, John C. Randolph wrote:
Very cool stuff! I especially like the -ifResponds HOM. When
did you come up with that?
[..]
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.
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.
Hmm...I think you're preaching to the choir here. HOM is not a
panacea (nor has it ever been promoted as such) but applicable to
coding situations where you see recurring patterns of code that you
cannot easily capture otherwise. The patterns that occur in
iteration are an example, as are things where you find yourself
mucking about with selectors or bracketing message sends.
Another point to realize is that HOM is at very early stages and this
has a number of implications. One is that we are not used to
thinking about problems in a messaging style, but rather in terms of
functions, methods, statements, and therefore try to translate
problems into that terminological framework. Another, well possibly
the same, is that as people start actually playing with it, it will
become clearer which applications it is suited for.
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.
More difficult than what? And for whom?
I also don't understand what you mean with a "hybrid of HOM and
traditional messages". HOM is always used in such a mix at various
levels.
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
As far as I am aware, Perl has some higher order functions, such as
map. I am not aware of a HOM implementation for Perl.
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.
Your mileage may vary, but that is actually one of the bits of HOM
that I myself find most compelling: it manages to be *both* concise
and absolutely clear and simple. What happens has both a simple
conceptual model that is easy to grasp and a syntactic structure that
manges to directly express the intended operation. I don't see how
this relates to Perl at all.
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.
Yes. This is a point I haven't covered much yet. In effect, if you
have a one-off, it may be OK to have an inline method instead of
giving it a name. However, this might apply to *any* situation not
just iteration, and it is certainly odd that you should *have to* use
inline methods in some situations.
My analysis is roughly as follows: you always use a HOM, in
principle, but you allow inline methods to be temporarily added to
class(es) in a specific context and these to be invoked anonymously.
I am guessing this is *conceptually* similar to inner classes in
Java, but it needs to be done using the current convenient syntax.
That's really only a very short analysis.
Cheers,
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
1d480c25f397c4786386135f8e8938e4
_______________________________________________
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