Adding fuel to the fire, note that [lang] 3.0 will include the Pair<L, R> class.
Matt On 1/28/11, Stephen Williams <s...@lig.net> wrote: > On 1/28/11 3:14 PM, James Ring wrote: >> Hey, >> >> On Fri, Jan 28, 2011 at 3:00 PM, Stephen Williams<scient...@gmail.com> >> wrote: >>> True, you shouldn't synchronize on any object that A) you want to change >>> and >>> B) can only be changed by being replaced by a newly constructed object. >>> If >>> Integer, for instance, had a setter method, then it could still have been >>> used in this way. However, it seems to be immutable. I generally just >>> create something like the following to synchronize: >> Just because an object is immutable doesn't mean that you shouldn't >> necessarily synchronize on it. > The point of the suggested link, which is valid, is to make sure you aren't > synchronizing on a variable when you are going to > replace the value of that variable by assignment. Since you are really > synchronizing on what the object variable is referencing, > assigning to it later means that the objects involved before and after > assignment are different objects. Therefore, the > synchronization is completely broken. >>> Object lockArg; >> For example, Object lockArg = new Object() is immutable but is fine >> for synchronization. >> >> FYI java.util.concurrent has a much better suite of synchronization >> utilities than the language primitives provide. > > Absolutely, very cool features. But not always needed. >>> ... >>> >>> About returning tuples: >>> Returning more than one value from a method has two reasonable solutions >>> that seem minimal for their use cases: returning a tuple as a single >>> value >>> or making one or more calls to a callback method. The simplest case is >>> when >>> multiple values need to be returned. While callbacks have their place >>> when >>> you need to trigger more operations incrementally, they are cumbersome as >>> you need to define a class and provide an implementation, although the >>> latter can be an anonymous implementation. Many have complained about >>> the >>> lack in Java of pair<>, however with the object reference system, it is >>> easy >>> to do this with arrays. If the types are all the same, like String[], >>> this >>> is completely typesafe. Otherwise, you can use Object[]. You can also >>> define a return type class to fill, however that is cumbersome. In >>> addition >>> to Object[], a TreeMap can be a good solution, especially when more than >>> a >>> few parameters are needed and they might change over time. >> Returning tuples indicates that you are missing some sort of >> abstraction that should be introduced to represent the thing you are >> returning. Defining a class and providing an implementation is way >> less cumbersome than dealing with the bugs that crop up when you fail >> to properly encapsulate your state. Returning a TreeMap is probably >> bad for the same reason. > > Certainly, that is the common analysis. And it can be true in many cases. > However, you could argue your point in the extreme: The > return value for any method should be a defined type. Rather than returning > an int, why not "ScreenWidthType"? There is a > balancing need, which most ignore or do not see until it is too late, to be > concise and not promote "class diarrhea". That is a > term I coined after working on a project where the primary development was > by an offshore team who never met an idea for creating > new classes that they couldn't apply several times a day. A single > transaction through the system involved substantially all of the > 600 classes that they had created in a few months. > > If you must create a return type, do it as an inner class right at the > definition of the method. Having many tiny classes with 10 > lines of real code each can become a huge complexity burden: complex > simplicity does not result in anything like the lowest total > complexity. If the types are common and key objects in your system, then a > separate abstraction is appropriate. That is seldom > true of everything in a system. > > As for the TreeMap method, both Qt/C++ and Objective-C includes a properties > system where arbitrary values can be ferried by > objects. For certain things, like returning sets that are potentially > variable such as the results of an XML parse, this is ideal. > >>> Stephen >> Regards, >> James > sdw > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
