commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: Pointers
Date Sat, 29 Jan 2011 18:47:36 GMT
Adding fuel to the fire, note that [lang] 3.0 will include the Pair<L, R> class.


On 1/28/11, Stephen Williams <> wrote:
> On 1/28/11 3:14 PM, James Ring wrote:
>> Hey,
>> On Fri, Jan 28, 2011 at 3:00 PM, Stephen Williams<>
>> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message