An AtomicObject does not contain references to any other object(s).

Some languages (such as CsharpLanguage and JavaLanguage since version 1.5) box and unbox primitives into AtomicObject''''''s. 

Many ValueObject''''''s are AtomicObject''''''s.
----
Would a String be atomic if it held objects of class Character?

''Many languages, including Lisp derivatives and Smalltalk, have two types of "strings". The first, "spelled like this" in Lisp and 'spelled like this' in Smalltalk, are essentially lists of characters (though they have additional features), and aren't considered atomic, though the constituent parts are all atomic. The second, 'spelledLikeThis or (quote spelledLikeThis) in Lisp, and #spelledLikeThis in Smalltalk, '''are''' atoms. While it is possible to get at the string representation of an atom in either language; two atoms with the same name are considered '''identical''' in both languages. Two strings with the same characters are considered equal but not necessarily identical; as strings can be mutated.''

Would a boolean be atomic if it held a pointer to class Boolean?

''Be careful; don't confuse a pointer/reference to an object with an object containing a pointer/reference to an object. Atomicity is only a property of objects, not of raw pointers/references.''

----
In languages where value types and pointers are distinct (e.g., C/C++), atomicity is straightforward. If there is a pointer in that struct, it isn't atomic.

In languages with a reference model of objects, defining atomic is less straightforward. If I have an object A which points to an object B, and the instance of B is private to A and not used outside A (nor is a reference to B ever supplied to clients of A), does the reference to B preclude A from being atomic? In C/C++, I might well embed the B in the A directly (no pointer or reference). In Java, I have no choice but to type "new B" in the constructor.

A possible looser definition of atomicity would suggest that if the graph of the object and it's dependencies (ad infinitum) is a finite tree (no cycles, etc.), the object is atomic. But such as definition would make many lists in LispLanguage atomic!

Atomicity may well be a matter of logical function, rather than a hard-and-fast criteria that you can blindly apply. It certainly makes sense to treat immutable strings as atoms (Lisp treats them so); I could think of several other compound datatypes that I would consider atomic. OTOH, treating a list as an atom is obviously bogus.

engineer_scotty (Scott Johnson)
----
I'm not sure that treating a list as atomic is all that bogus, assuming its constituents are all atomic and the list is immutable. After all, couldn't we replace this list with an array of atomic types, which is logically equivalent to a string? I could imagine a Lisp implementation that defined CAR and CDR on arrays like this:

 (defun car (array)
    (aref (array 0)))

 (defun cdr (array)
    (aref (array 1)))
As long as the array never has to grow or shrink, this should give the same semantics as the normal ConsCell based implementation.

Of course, this requires that the list/array be immutable - otherwise we run into problems when we try to add new elements. But ''logically'', it seems like this is just as legitimate as a series of CONS cells, and if the list is private and not referenced outside a structure, it would allow us to embed it flatly within a data structure.

I wonder if any compilers use this as an optimization technique, flattening out links into indexes when they can prove the data structure is not accessed outside of an object.

-- JonathanTang