Delegates...?

[Mark Space]

Just look at my first reply to the OP.

I'd would have liked to see something actually interface into a working
"view" that is, an actual GUI component in the Java API, but ok, I guess
you did provide an example.

 

[Lew]

Especially since I think you're mistaken to
characterize me as being knowledgeable about Java. I've only been using
it a couple of months, for crying out loud. Just how knowledgeable
could I be?

You may not feel expert in Java details yet, at this point, but it is
abundantly clear that you understand the language very well, and you reason
correctly about it with clear evidence for your points. I'm sure you don't
feel that knowledgeable yet, but I've only been using Java for nine years and
I barely feel now that I understand the language. Anyone who reads Usenet
knows that I frequently make inaccurate or incomplete remarks about Java, and
I do feel that I know the language pretty well. The main reason I participate
here is because the corrections, arguably more so than posts who reinforce my
conclusions, train me and refine my understanding more quickly and ruthlessly
than any other method I've found.

I suggest to the OP that they consider whether merely having a recipe to
answer one question really helps them understand Java programming, or whether
a deep knowledge of why things are a certain way, even if wrongly chosen, in
the language does more to engender mastery. I assert that without deep
understanding of the issues involved, one is doomed to be a mere hack. The
big opportunities and joy in programming come from being able to solve
problems or create systems that are novel - if anyone could do it, everyone
would do it.

If the OP were to claim that deep understanding is not necessary to their
purpose, and all they want is a rote response to their limited question, I
would decry that response as detrimental to their growth as a programmer.

I suggest that even your vehement disagrements with the Sun white paper on why
they don't use delegates, and your humorous rhetoric denigrating it ("chaff",
etc.), serve to sharpen one's understanding of the matter even more. You and
I have been excellent partners, laying out the information, pricking holes in
its logic, and actually giving incentive for others to read the article to
understand why I proffered it and you think it's hokum. Thus we have
benefited the community and provided growth for all.

 

[Peter Duniho]

I'd would have liked to see something actually interface into a working
"view" that is, an actual GUI component in the Java API,

Well, your example didn't have a GUI.

It's true that I only ported the code the OP posted. I didn't include a
main() method or directives to make the sample complete. But I took as
granted the OP didn't need it, and I would be surprised if you had any
trouble coming up with an appropriate one.

For that matter, the one you posted is nearly sufficient. The only
difference being that you'd need to make the CallTest() and CallTest2()
methods public (or provide public methods that would call them), and then
call those methods from the main() method, rather than calling the
TestMethod() and TestMethod2() methods directly as your sample does. I
would think you could make those changes easily enough.

but ok, I guess you did provide an example.

And do you now see how that example differs from the one you offered?

Or do you need something more specific?

Pete

 

[Gavin Metcalfe]

In other words, your example is backwards as compared to what the OP was

asking.

Correct that example is backwards to what I am trying to do. The presenter
has references to the View and the Model and calls methods that way. The
View and Model on the other hand call the delegate which is like a
function pointer to the methods in the presenter.

See this document for a more in depth explanation of "Presenter First".

http://www.atomicobject.com/files/PresenterFirstAgile2006.pdf

Gav

 

[Mark Space]

Well, your example didn't have a GUI.

"Examples," plural. And the heck they didn't. Did you scroll down?
There were three working programs in my one post.

 

[Mark Space]

Correct that example is backwards to what I am trying to do. The presenter
has references to the View and the Model and calls methods that way. The
View and Model on the other hand call the delegate which is like a
function pointer to the methods in the presenter.

Check the actual Swing examples I provided later in that post. The
first one was just a quick example of how to do a delegate, you can
substitute any method invocation you like.

 

[Peter Duniho]

"Examples," plural. And the heck they didn't.

I was talking about the very first one.

Did you scroll down? There were three working programs in my one post.

I know. But your requirement for a GUI seems arbitrary, unnecessary, and
not even followed by you in all of your examples.

But even if you had, what of it? Is a GUI required in order to
demonstrate the principles? No. And why duck the question I asked? Do
you now understand the error you made? Or are you going to continue to
insist that I'm "all wet"?

I understand the temptation to go on the offensive with irrelevancies so
that you can avoid the real question. But I don't see the point in doing
so.

Pete

 

[Mark Space]

But even if you had, what of it? Is a GUI required in order to
demonstrate the principles? No. And why duck the question I asked? Do
you now understand the error you made? Or are you going to continue to
insist that I'm "all wet"?

My point about the GUI is that Swing seems to provide already most of
what the OP is asking for. There's no reason to build the presenter and
delegates from scratch. When someone says "I don't know enough Java to
even pass an object which hold a method" I think it helps to give them a
steer in the right direction.

I'm reading the link the OP provided now about MVP. The more I do so,
the more I think "the view they describe just like Swing." Actually on
page four they just got into talking about using an automated builder
for creating presenters, which is good. And I like rigor of the model.
But I'm thinking my original instincts that the OP should be looking
heavily at what's already been done in Swing were right on.

What I didn't like about your example was that it seems to re-implement
things that it really should not.

I'm ducking the question of my first example because it was really just
an example of delegates in Java. The whole point was to lead up to the
third example. Maybe that was a bad idea or unnecessary, but I cut out
as much as I could to keep the line count down. It's not really
important to me though.

 

[Arne Vajhøj]

I suggest that people read the article at
<http://java.sun.com/docs/white/delegates.html>
for themselves, and then read up on C# delegates and think about the
issues for themselves.

I'm not saying I agree with Sun's reasoning, but it's clear from it that
they exercised the human capacity for rational thinking before deciding
whether to include delegates in the Java language.

I don't think their arguments are very valid.

Delegates is a nice feature in C# and does not seem to have
any side effect when we look at it from the practical perspective.

The *only* valid argument I can see against delegates is the
size of the language: more languages features does not make a
language better - just ensure it has the same future as PL/I and Ada.

Unfortunately that opinion is not in favor with either the
Java or the C# masters.

Arne

 

[Mike Schilling]

I don't think their arguments are very valid.

Delegates is a nice feature in C# and does not seem to have
any side effect when we look at it from the practical perspective.

The *only* valid argument I can see against delegates is the
size of the language: more languages features does not make a
language better - just ensure it has the same future as PL/I and
Ada.

But if you add delegates, you remove the need for inner classes to
implement callbacks. (Nested classes could be retained as
code-structuring devices, but the notion of owning instance can go.)
To my mind, delegates are much simpler than inner classes, so this is
a net gain in simplicity.

 

[Arne Vajhøj]

But if you add delegates, you remove the need for inner classes to
implement callbacks. (Nested classes could be retained as
code-structuring devices, but the notion of owning instance can go.)
To my mind, delegates are much simpler than inner classes, so this is
a net gain in simplicity.

You can never remove features from a language.

The curse of compatibility.

Arne

 

[Mike Schilling]

You can never remove features from a language.

Sure; I meant that delgates could have been added instead of inner
classes. Adding them now would be pointless.