Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #18521 > unrolled thread

Wormholes

Back to article view | Back to comp.lang.java.programmer

Contents

  Wormholes Roedy Green <see_website@mindprod.com.invalid> - 2012-09-03 18:12 -0700
    Re: Wormholes eric@invalid.com (EricF) - 2012-09-04 02:06 +0000
      Re: Wormholes Roedy Green <see_website@mindprod.com.invalid> - 2012-09-04 10:08 -0700
      Re: Wormholes Wanja Gayk <brixomatic@yahoo.com> - 2012-09-09 13:55 +0200
    Re: Wormholes Arne Vajhøj <arne@vajhoej.dk> - 2012-09-03 22:34 -0400
      Re: Wormholes Stuart <DerTopper@web.de> - 2012-09-04 12:15 +0200
    Re: Wormholes markspace <-@.> - 2012-09-03 21:00 -0700
      Re: Wormholes Robert Klemme <shortcutter@googlemail.com> - 2012-09-04 07:08 +0200
    Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-04 08:47 +0200
      Re: Wormholes Lew <noone@lewscanon.com> - 2012-09-04 03:10 -0700
        Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-04 16:09 +0200
          Re: Wormholes Gene Wirchenko <genew@ocis.net> - 2012-09-04 08:34 -0700
            Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-04 17:46 +0200
              Re: Wormholes Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-09-04 09:31 -0700
          Re: Wormholes Lew <lewbloch@gmail.com> - 2012-09-04 11:14 -0700
          Re: Wormholes Arne Vajhøj <arne@vajhoej.dk> - 2012-09-04 19:59 -0400
      Re: Wormholes Roedy Green <see_website@mindprod.com.invalid> - 2012-09-04 13:20 -0700
        Re: Wormholes Arne Vajhøj <arne@vajhoej.dk> - 2012-09-04 20:00 -0400
        Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-05 09:01 +0200
        Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-05 09:02 +0200
        Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-05 09:02 +0200
          Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-05 09:03 +0200
        Re: Wormholes markspace <-@.> - 2012-09-05 17:34 -0700
    Re: Wormholes Steven Simpson <ss@domain.invalid> - 2012-09-04 14:18 +0100
      Re: Wormholes Robert Klemme <shortcutter@googlemail.com> - 2012-09-05 21:51 +0200
        Re: Wormholes Steven Simpson <ss@domain.invalid> - 2012-09-05 23:26 +0100
          Re: Wormholes Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-09-06 09:32 +0000
            Re: Wormholes Steven Simpson <ss@domain.invalid> - 2012-09-06 11:47 +0100
              Re: Wormholes Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-09-06 15:10 +0000
                Re: Wormholes Steven Simpson <ss@domain.invalid> - 2012-09-06 20:12 +0100
                  Re: Wormholes Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-09-06 21:08 +0000
    Re: Wormholes Nigel Wade <nmw@ion.le.ac.uk> - 2012-09-04 17:26 +0100
    Re: Wormholes Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-09-04 09:28 -0700
    Re: Wormholes David Lamb <dalamb@cs.queensu.ca> - 2012-09-04 16:54 -0400

Page 1 of 2  [1] 2  Next page →

#18521 — Wormholes

I run into this sort of problem fairly often.

I have a method x that calls method y through a long chain of
intermediate calls.

I decide to add a feature.  Method x has access to information to
decide if the feature should be implemented.  Method y is where the
implementation is.

Somehow I must pass information down the long chain from x to y.  This
means changing the signatures of all the intermediate methods, and
adjusting code to the new way.  This can cause ripples incommensurate
with the triviality of the change.

I imagined some sort of wormhole to allow information in one place to
simply be known somewhere else without the excess exposure of public
variables or tediously arranging transport.  I read about Eiffel a
long time ago. IIRC you could provide a list of precisely who could
see any given information.

I wondered if anyone had thoughts on ways of tackling such a problem.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
A new scientific truth does not triumph by convincing its opponents and making them see the light,
but rather because its opponents eventually die, and a new generation grows up that is familiar with it.
~ Max Planck 1858-04-23 1947-10-04 

[toc] | [next] | [standalone]

#18523

In article <0ska4895k2mp2j5fb5p4qnue7lsbdpoeoo@4ax.com>, Roedy Green <see_website@mindprod.com.invalid> wrote:
>I run into this sort of problem fairly often.
>
>I have a method x that calls method y through a long chain of
>intermediate calls.
>
>I decide to add a feature.  Method x has access to information to
>decide if the feature should be implemented.  Method y is where the
>implementation is.
>
>Somehow I must pass information down the long chain from x to y.  This
>means changing the signatures of all the intermediate methods, and
>adjusting code to the new way.  This can cause ripples incommensurate
>with the triviality of the change.
>
>I imagined some sort of wormhole to allow information in one place to
>simply be known somewhere else without the excess exposure of public
>variables or tediously arranging transport.  I read about Eiffel a
>long time ago. IIRC you could provide a list of precisely who could
>see any given information.
>
>I wondered if anyone had thoughts on ways of tackling such a problem.

Having a long chain of intermediate calls sounds like a bad idea, lots of 
coupling. Can you refactor to get rid of or at least prune the chain?

Eric

[toc] | [prev] | [next] | [standalone]

#18543

On Tue, 04 Sep 2012 02:06:22 GMT, eric@invalid.com (EricF) wrote,
quoted or indirectly quoted someone who said :

>Having a long chain of intermediate calls sounds like a bad idea, lots of 
>coupling. Can you refactor to get rid of or at least prune the chain?

I think I misdescribed this.  x knows a detail of how the
implementation should work.  The code that uses that detail in y is at
the end of a long chain, not the implementation itself.  The
implementation is quite complicated, so if I shortened the chain, I
woulds have to increase the size of the methods on the way there.

-- 
Roedy Green Canadian Mind Products http://mindprod.com
A new scientific truth does not triumph by convincing its opponents and making them see the light,
but rather because its opponents eventually die, and a new generation grows up that is familiar with it.
~ Max Planck 1858-04-23 1947-10-04 

[toc] | [prev] | [next] | [standalone]

#18625

In article <k23nn7$urk$1@dont-email.me>, eric@invalid.com says...

> >I wondered if anyone had thoughts on ways of tackling such a problem.
> 
> Having a long chain of intermediate calls sounds like a bad idea, lots of 
> coupling. Can you refactor to get rid of or at least prune the chain?

Let's see, you need to get Information from A to C:

The Law of Demeter incompliant naive solution:

class A{
 private B b = new B();
 {
  b.getC().setValue("hello world");
 }
}

class B{
 private C c = new C();
 C getC(){return c;}
}

class C{
  private String value;
  void setValue(String v){c.setValue(v);}
}

Problem: if you change C, you need to change A aswell, eveb though these 
should not be closely related.

LOD-compliant naive solution:

class A{
  private B b = new B();
 {
  b.setValue("hello world")
 }
}

class B{
  private C c = new C();
  void setValue(String v){c.setValue(v);}
}

class C{
  private String value;
  void setValue(String v){c.setValue(v);}
}

The only difference with the previous is that B won't leak its internals 
to A, so you could change C without affecting A, by putting some 
conversion code to B.

You could use a visitor too:

class Visitor{
 private String value;
 Visitor(String value){this.value=value;}

 void visit(C c){
  c.setValue(value);
 }
}

class A{
 private B b = new B();
 {
  b. accept(new Visitor("Hello World"));
 }
}

class B{
 private C c = new C();
 accept(Visitor v){
  c.accept(v);
 }
}

class C{
 private String value;
 accept(Visitor v){
  v.visit(this);
 }
}

This way your can change C without having to change A or B, by adding 
some conversion code to the Visitor.

The third thing you could do is send Messages over a central message 
bus, that every class may listen to:

interface MessageBusStop{
 void stop(Bus bus);
}

abstract Message{
 private Object id;
 private Object payload;
 Message(Object id, Object payload){
  this.id=id;
  this.payload=payload;
 }
 boolean isMessageId(Object id){this.id.equals(id);}
 Object getPayload(){return payload;}
}

class A{
 Bus bus = Application.getMessageBus();
 {
 bus.sendMessage(new Message(Messages.NEW_TITLE,"Hello World"));
 }
}

class C implements MessageBusStop{
 private String s;
 private Bus bus = Application.registerNewMessageBusStop(this);

 void stop(Bus b){
  if(b.isMessageId(Messages.NEW_TITLE)){
   s = (String)bus.peekMessagePayload();
  }
 }
}

Problem is that a single message may involve a lot of classes to see if 
they are responsible to handle the message, but there are possibilities 
to make the central bus only stop at those classes interested in certain 
IDs or certain types of IDs, so this concept is pretty nice.
The problem there is with many objects reactibng to messages that you 
have to make sure that the order in which objects react to messages is 
not crucial.

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#18524

On 9/3/2012 9:12 PM, Roedy Green wrote:
> I run into this sort of problem fairly often.
>
> I have a method x that calls method y through a long chain of
> intermediate calls.
>
> I decide to add a feature.  Method x has access to information to
> decide if the feature should be implemented.  Method y is where the
> implementation is.
>
> Somehow I must pass information down the long chain from x to y.  This
> means changing the signatures of all the intermediate methods, and
> adjusting code to the new way.  This can cause ripples incommensurate
> with the triviality of the change.
>
> I imagined some sort of wormhole to allow information in one place to
> simply be known somewhere else without the excess exposure of public
> variables or tediously arranging transport.  I read about Eiffel a
> long time ago. IIRC you could provide a list of precisely who could
> see any given information.
>
> I wondered if anyone had thoughts on ways of tackling such a problem.

If you pass a single big object instead of multiple simple types values,
then there should not really be any impact down the chain.

Arne

[toc] | [prev] | [next] | [standalone]

#18531

On 9/3/2012 9:12 PM, Roedy Green wrote:
>> I run into this sort of problem fairly often.
>>
>> I have a method x that calls method y through a long chain of
>> intermediate calls.
>>
>> I decide to add a feature.  Method x has access to information to
>> decide if the feature should be implemented.  Method y is where the
>> implementation is.
>>
>> Somehow I must pass information down the long chain from x to y.  This
>> means changing the signatures of all the intermediate methods, and
>> adjusting code to the new way.  This can cause ripples incommensurate
>> with the triviality of the change.
>>
>> I imagined some sort of wormhole to allow information in one place to
>> simply be known somewhere else without the excess exposure of public
>> variables or tediously arranging transport.  I read about Eiffel a
>> long time ago. IIRC you could provide a list of precisely who could
>> see any given information.
>>
>> I wondered if anyone had thoughts on ways of tackling such a problem.

On 9/4/12 4:34 AM Arne Vajhøj wrote:
> If you pass a single big object instead of multiple simple types values,
> then there should not really be any impact down the chain.
>
> Arne

+1

I had to write some generic measurement routines that would be the same 
for almost all of our measurement machines (strategy pattern). However, 
some machines would acquire additional data on the way, so I had to pass 
this additional information to the internal measurement routines and the 
additional measurement data back to the calling routines. I turned all 
parameters and results into objects that could be subclassed as needed. 
I think that this is nothing too unusual and scales pretty well.

Regards,
Stuart

[toc] | [prev] | [next] | [standalone]

#18526

On 9/3/2012 6:12 PM, Roedy Green wrote:
> I run into this sort of problem fairly often.
>
> I have a method x that calls method y through a long chain of
> intermediate calls.


I think I'm with Eric F. on this.  Given some long chain of calls: X, A, 
B, C D, ... Y, can that be refactored so that X calls Y directly?

   void methodX()  {
     A();
   }

to

   void methodX() {
     AResult result = A();
     X( result, otherData );
   }

I'm thinking that if your methods have to pass data through a long chain 
of calls, then the code is badly structured period.  You might as well 
use the opportunity to refactor rather than trying to invent a "wormhole."

I can think of at least one way to implement a wormhole.  I'm just not 
going to go there because it's a terrible idea.

[toc] | [prev] | [next] | [standalone]

#18527

On 04.09.2012 06:00, markspace wrote:
> On 9/3/2012 6:12 PM, Roedy Green wrote:
>> I run into this sort of problem fairly often.

That sounds like a warning sign for the way you structure code.

>> I have a method x that calls method y through a long chain of
>> intermediate calls.

> I'm thinking that if your methods have to pass data through a long chain
> of calls, then the code is badly structured period.  You might as well
> use the opportunity to refactor rather than trying to invent a "wormhole."

If there are public library methods involved the situation is much 
worse: then Roedy probably cannot refactor but has to add functionality...

> I can think of at least one way to implement a wormhole.  I'm just not
> going to go there because it's a terrible idea.

I am pretty confident I know what you mean.  I would even go as far as 
to calling usage of that "opening a can of worms".  There are also 
negative side effects on testability...

Kind regards

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#18529

Roedy Green <see_website@mindprod.com.invalid> writes:

> Somehow I must pass information down the long chain from x to y.  This
> means changing the signatures of all the intermediate methods, and
> adjusting code to the new way.  This can cause ripples incommensurate
> with the triviality of the change.

Add a static variable to x accessible to y.

[toc] | [prev] | [next] | [standalone]

#18530

Zermelo wrote:
> Roedy Green writes:
>> Somehow I must pass information down the long chain from x to y.  This
>> means changing the signatures of all the intermediate methods, and
>> adjusting code to the new way.  This can cause ripples incommensurate
>> with the triviality of the change.
>
> Add a static variable to x accessible to y.

Why static?

Why not a getter method?

What about the Law of Demeter?

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#18534

Lew <noone@lewscanon.com> writes:

> Why static?
>

Because a static variable is accessible from every methods. The same is
not true for an instance variable.
 
> Why not a getter method?
>

I think the OP can reach this solution by himself.

> What about the Law of Demeter?

The OP seems unwilling to restructure his code.

[toc] | [prev] | [next] | [standalone]

#18536

On Tue, 04 Sep 2012 16:09:54 +0200, Zermelo
<zermelo@teletu.it.nospam.invalid> wrote:

>Lew <noone@lewscanon.com> writes:
>
>> Why static?

>Because a static variable is accessible from every methods. The same is
>not true for an instance variable.

     The horror of global variables raises its head.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#18537

Gene Wirchenko <genew@ocis.net> writes:

> The horror of global variables raises its head.
Without substantial refectoring I don't see any other solution.

[toc] | [prev] | [next] | [standalone]

#18542

On 9/4/12 8:46 AM, Zermelo wrote:
> Gene Wirchenko <genew@ocis.net> writes:
>
>> The horror of global variables raises its head.
> Without substantial refectoring I don't see any other solution.
>
The solution is substantial refactoring. Global variables introduce all 
kinds of problems, including but not limited to: Packratting, 
concurrency issues, debugging problems, "action at a distance" problems, 
etc...

[toc] | [prev] | [next] | [standalone]

#18544

On Tuesday, September 4, 2012 7:10:01 AM UTC-7, Zermelo wrote:
> Lew writes:
>> Why static?
> 
> Because a static variable is accessible from every methods. The same is
> not true for an instance variable.

Yes, it is, if the OP follows the advice given by other respondents to pass 
around a data object.

And static variables carry grave risks.

>> Why not a getter method?
> 
> I think the OP can reach this solution by himself.

Perhaps, but it's not what you recommended.

>> What about the Law of Demeter?
> 
> The OP seems unwilling to restructure his code.

So you recommend a land-mine strategy to what, punish him
for that?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#18547

On 9/4/2012 10:09 AM, Zermelo wrote:
> Lew <noone@lewscanon.com> writes:
>> Why static?
>
> Because a static variable is accessible from every methods. The same is
> not true for an instance variable.
>
>> Why not a getter method?
>
> I think the OP can reach this solution by himself.

If one decide to go the "global route", then a singleton with
a non static getter seems to be a much nicer solution than a
directly accessible static field.

Arne

[toc] | [prev] | [next] | [standalone]

#18545

On Tue, 04 Sep 2012 08:47:18 +0200, Zermelo
<zermelo@teletu.it.nospam.invalid> wrote, quoted or indirectly quoted
someone who said :

>Add a static variable to x accessible to y.

it would have to have default scope.  I hoping there was a technique
that would behave like that, but which would not expose the variable
to the entire package, when really only one method should use that
variable. 

The techniques that I can think of  are default scope variable or pass
value down call chain to where it is used.   Are there any others?
-- 
Roedy Green Canadian Mind Products http://mindprod.com
A new scientific truth does not triumph by convincing its opponents and making them see the light,
but rather because its opponents eventually die, and a new generation grows up that is familiar with it.
~ Max Planck 1858-04-23 1947-10-04 

[toc] | [prev] | [next] | [standalone]

#18548

On 9/4/2012 4:20 PM, Roedy Green wrote:
> On Tue, 04 Sep 2012 08:47:18 +0200, Zermelo
> <zermelo@teletu.it.nospam.invalid> wrote, quoted or indirectly quoted
> someone who said :
>> Add a static variable to x accessible to y.
>
> it would have to have default scope.  I hoping there was a technique
> that would behave like that, but which would not expose the variable
> to the entire package, when really only one method should use that
> variable.
>
> The techniques that I can think of  are default scope variable or pass
> value down call chain to where it is used.

You should pass it down.

Arne

[toc] | [prev] | [next] | [standalone]

#18550

Roedy Green <see_website@mindprod.com.invalid> writes:

> The techniques that I can think of  are default scope variable or pass
> value down call chain to where it is used.   Are there any others?

You can also overload method y and add an extra parameter.

[toc] | [prev] | [next] | [standalone]

#18551

Roedy Green <see_website@mindprod.com.invalid> writes:

> The techniques that I can think of  are default scope variable or pass
> value down call chain to where it is used.   Are there any others?

You can also overload method y and add an extra parameter.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web