Because knowing the calling object might not be sufficient... you may
want to know the exact method that called, and further, you may not want
to introduce the extra parameter, which changes the public interface.
Mind you, I AM NOT saying this is a good idea or anything, but I am a
little surprised that everyone seems to think it's such a terrible
idea... I mean, if you believe the original request was reasonable to
begin with, I'm not sure I see a major problem with this solution (aside
from performance). I'm not arguing for anyone doing this, but now I'm
curious why it elicited such strong objections :)
Frank
netsql wrote:
Wow.
Why not
method(args, this);
so you know the calling object.
or better version.
register(this);
method(arg);
Plenty of OO designs.
Or just don't make it public, there are 3 "modifier" choices left other
then public, including package/friend.
I would just expose an API interface and have comments "for internal
use" for implementation, which I would then not JavaDoc! Just JavaDoc
the API interface.
.V
Frank W. Zammetti wrote:
I saw a very similar question asked a few months back in a general Java
forum, and I suggested an answer that I've never had the chance to
actually try out... the theory is interesting though...
In the method you want to "protect", immediately throw an exception and
catch it. Then, parse the stack trace and see who the caller was. If
it's not a class you want to have access to the method, throw an
IllegalAccessException.
Again, it's one of those things that sounds good in your head, I have no
idea if it translates to anything workable :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
