- interface View(T) ¶#
-
this is the base interface for most classes in this package.
Doug Lea
@version 0.93
For an introduction to this package see Overview .
- View!(T) duplicate() [public] ¶#
-
All Views implement duplicate
- bool contains(T element) [public] ¶#
-
Report whether the View contains element.
Behaviorally equivalent to instances(element) >= 0.
@param element the element to look for
true iff contains at least one member that is equal to element.
- uint size() [public] ¶#
-
Report the number of elements in the View.
No other spurious effects.
number of elements
- bool drained() [public] ¶#
-
Report whether this View has no elements.
Behaviorally equivalent to size() == 0.
true if size() == 0
- uint mutation() [public] ¶#
-
All collections maintain a `version number'. The numbering
scheme is arbitrary, but is guaranteed to change upon every
modification that could possibly affect an elements() enumeration traversal.
(This is true at least within the precision of the `int' representation;
performing more than 2^32 operations will lead to reuse of version numbers).
Versioning
may be conservative with respect to `replacement' operations.
For the sake of versioning replacements may be considered as
removals followed by additions. Thus version numbers may change
even if the old and new elements are identical.
All element() enumerations for Mutable Collections track version
numbers, and raise inconsistency exceptions if the enumeration is
used (via get()) on a version other than the one generated
by the elements() method.
You can use versions to check if update operations actually have any effect
on observable state.
For example, clear() will cause cause a version change only
if the collection was previously non-empty.
- bool allows(T element) [public] ¶#
-
Report whether the View COULD contain element,
i.e., that it is valid with respect to the View's
element screener if it has one.
Always returns false if element == null.
A constant function: if allows(v) is ever true it is always true.
(This property is not in any way enforced however.)
No other spurious effects.
true if non-null and passes element screener check
- uint instances(T element) [public] ¶#
-
Report the number of occurrences of element in View.
Always returns 0 if element == null.
Otherwise T.equals is used to test for equality.
@param element the element to look for
the number of occurrences (always nonnegative)
- GuardIterator!(T) elements() [public] ¶#
-
Return an enumeration that may be used to traverse through
the elements in the View. Standard usage, for some
ViewT c, and some operation `use(T obj)':
for (Iterator e = c.elements(); e.more(); )
use(e.value());
(The values of get very often need to
be coerced to types that you know they are.)
All Views return instances
of ViewIterator, that can report the number of remaining
elements, and also perform consistency checks so that
for MutableViews, element enumerations may become
invalidated if the View is modified during such a traversal
(which could in turn cause random effects on the ViewT.
TO prevent this, ViewIterators
raise CorruptedIteratorException on attempts to access
gets of altered Views.)
synchronized construct
around code blocks that do traversals. (Use with care though,
since such constructs can cause deadlock.)
Guarantees about the nature of the elements returned by get of the
returned Iterator may vary accross sub-interfaces.
In all cases, the enumerations provided by elements() are guaranteed to
step through (via get) ALL elements in the View.
Unless guaranteed otherwise (for example in Seq), elements() enumerations
need not have any particular get() ordering so long as they
allow traversal of all of the elements. So, for example, two successive
calls to element() may produce enumerations with the same
elements but different get() orderings.
Again, sub-interfaces may provide stronger guarantees. In
particular, Seqs produce enumerations with gets in
index order, ElementSortedViews enumerations are in ascending
sorted order, and KeySortedViews are in ascending order of keys.
an enumeration e such that
e.remaining() == size() &&
foreach (v in e) has(e)
- int opApply(int delegate (inout T value) dg) [public] ¶#
-
traverse the collection content. This is cheaper than using an
iterator since there is no creation cost involved.
- T[] toArray() [public] ¶#
-
expose collection content as an array
- bool matches(View other) [public] ¶#
-
Report whether other has the same element structure as this.
That is, whether other is of the same size, and has the same
elements() properties.
This is a useful version of equality testing. But is not named
`equals' in part because it may not be the version you need.
The easiest way to decribe this operation is just to
explain how it is interpreted in standard sub-interfaces:
- Seq and ElementSortedView: other.elements() has the
same order as this.elements().
- Bag: other.elements has the same instances each element as this.
- Set: other.elements has all elements of this
- Map: other has all (key, element) pairs of this.
- KeySortedView: other has all (key, element)
pairs as this, and with keys enumerated in the same order as
this.keys().
@param other, a View
- void checkImplementation() [public] ¶#
-
Check the consistency of internal state, and raise exception if
not OK.
These should be `best-effort' checks. You cannot always locally
determine full consistency, but can usually approximate it,
and validate the most important representation invariants.
The most common kinds of checks are cache checks. For example,
A linked list that also maintains a separate record of the
number of items on the list should verify that the recorded
count matches the number of elements in the list.
This method should either return normally or throw: