This shows you the differences between two versions of the page.
why_isn_t_it_dci_if_you_use_a_wrapper_object_to_represent_the_role [2014/01/14 23:24] jcoplien |
why_isn_t_it_dci_if_you_use_a_wrapper_object_to_represent_the_role [2014/01/26 21:10] (current) jcoplien |
||
---|---|---|---|
Line 35: | Line 35: | ||
And in my [[http://fulloo.info/Examples/RubyExamples/Dijkstra/DijkstraListing.html|Dijkstra example]], I have done exactly that. | And in my [[http://fulloo.info/Examples/RubyExamples/Dijkstra/DijkstraListing.html|Dijkstra example]], I have done exactly that. | ||
- | A fundamental problem arises in wrapped implementations. Let's say that I wrap domain class instance O with role wrapper south_neighbor. At some point the same object is wrapped with the role west_neighbor | + | A fundamental problem arises in wrapped implementations. Let's say that I wrap domain class instance O with role wrapper ''south_neighbor''. At some point the same object is wrapped with the role ''west_neighbor'' |
in another iteration (or recursion) of Dijkstra's algorithm. Which of these is true? | in another iteration (or recursion) of Dijkstra's algorithm. Which of these is true? | ||
Line 42: | Line 42: | ||
west_neighbor .equal? south_neighbor</code> | west_neighbor .equal? south_neighbor</code> | ||
- | It depends. The wrapping people say you can "fake out" the ''=='' case because, after all, the object paradigm doesn't stipulate what value comparison means. But you can't fake out ''.equal?'' without violating object identity. In theory a wrapper could re-define .equal? but it's a real mess. What if the wrapped object were wrapped again? How many levels deep of fake-out does one need? How does one know whether to propagate the fake-out or to take the pointer directly? And how about other parts of application code that honestly depend on on .equal? meaning "object identity" for real? | + | It depends. The wrapping people say you can "fake out" the ''=='' case because, after all, the object paradigm doesn't stipulate what value comparison means. But you can't fake out ''.equal?'' without violating object identity. In theory a wrapper could re-define ''.equal?'' but it's a real mess. What if the wrapped object were wrapped again? How many levels deep of fake-out does one need? How does one know whether to propagate the fake-out or to take the pointer directly? And how about other parts of application code that honestly depend on on .equal? meaning "object identity" for real? |
The Dijkstra example is a no-win scimitar for wrapper aficionados. That's why, with wrappers, you can only //almost// makes it work. I hope you don't work for a company with the goal of delivering software to me that //almost// works... That's where the wrapper folks belong. | The Dijkstra example is a no-win scimitar for wrapper aficionados. That's why, with wrappers, you can only //almost// makes it work. I hope you don't work for a company with the goal of delivering software to me that //almost// works... That's where the wrapper folks belong. | ||
Line 59: | Line 59: | ||
To not understand the fundamental failure of wrappers is to have only a shallow understanding of object-oriented programming. (And you have this straight from the guy who popularized PIMPLs ([[http://c2.com/cgi/wiki?PimplIdiom|http://c2.com/cgi/wiki?PimplIdiom]]).) | To not understand the fundamental failure of wrappers is to have only a shallow understanding of object-oriented programming. (And you have this straight from the guy who popularized PIMPLs ([[http://c2.com/cgi/wiki?PimplIdiom|http://c2.com/cgi/wiki?PimplIdiom]]).) | ||
+ | |||
+ | ---- | ||
+ | |||
+ | |||
+ |