Re: [ANN] HOM paper available
Re: [ANN] HOM paper available
- Subject: Re: [ANN] HOM paper available
- From: Steve Weller <email@hidden>
- Date: Fri, 9 Sep 2005 12:59:23 -0700
For HOM in Objective-C I would like to see some alternate syntax so
it is clear that HOM is being used and nip the nested bracketting in
the bud. My suggestion would be to use dots instead of [ ].
[myobject.ifResponds dosomething]
for instance. Do HOMs take arguments? I don't think I saw any.
On Sep 9, 2005, at 10:22 AM, Marcel Weiher wrote:
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
--
Watch me learn Cocoa http://homepage.mac.com/bagelturf/
_______________________________________________
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