Index - All Packages - All Categories - All Classes

Class ImmuTable

ImmuTable are to ScruTables much like ImmuSets are to ScruSets. See ImmuSet.

The ImmuTable subclass of tables represents all tables which CANNOT be side-effected during operations on them. They are intended to represent mathematical abstractions (such as vectors) and are intended to be used in a functional-programming style. Operations are provided for building new ImmuTables out of old ones.

Package: Udanax-Gold
All Superclasses: Object Heaper ScruTable
Immediate Subclasses: ImmuTableOnMu OffsetImmuTable
Protocols: Object
Categories: Xanadu-Collection-Tables

Class Methods

make: something

(something isKindOf: MuTable)
ifTrue: [^self makeMuTable: something].

makeCoordinateSpace: cs

An empty ImmuTable whose domain space is 'cs'.

offsetImmuTable: aTable with: aDsp

Instance Methods

actualHashForEqual

Overrides: ScruTable
Overridden by: OffsetImmuTable

asImmuTable

Overrides: ScruTable

asMuTable

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

combineWith: other

Similar to unionWith. In particular, if 'a = b->combineWith(c);', then:
'a->domain()->isEqual(b->domain()->unionWith(c->domain())' and
'a->range()->isSubsetOf(b->range()->unionWith(c->range())'.
(Note that the domain case uses XuRegion::unionWith, while the range case
uses ImmuSet::unionWith.)

Despite this correspondence, unionWith is symmetrical while combineWith is not.
Given that the two input tables have different associations for a given key,
one gets to dominate. I need to specify which one here, but the code seems
inconsistent on this question. Until this is resolved, console youself with the
thought that if the tables don't conflict we have a simple unionWith of the two
sets of associations (and the 'isSubsetOf' above can be replaced with 'isEqual').

Overridden by: ImmuTableOnMu OffsetImmuTable

coordinateSpace

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

copy

don't need to actually make a copy, as this is immutable

Overrides: ScruTable

count

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

domain

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

emptySize: size

The idea of a 'size' argument would seem kind of ridiculous here as the resulting empty table can't be changed.

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

fetch: key

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

includesIntKey: aKey

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

includesKey: aKey

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

intFetch: key

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

isEmpty

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

isEqual: other

Overrides: ScruTable

runAt: key

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

runAtInt: key

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

stepper: order

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

subTable: reg

Overrides: ScruTable
Overridden by: ImmuTableOnMu OffsetImmuTable

transformedBy: dsp

Return a ScruTable with the domain of the receiver transformed by the Dsp.
'table->transformedBy(d)->fetch(p)' is equivalent to
'table->fetch(d->of(p))'.

See ScruTable::subTable for caveats regarding whether we return a snapshot
or a view. All the same caveats apply.

In this case of transforming an ImmuTable, it makes sense to return an ImmuTable.

Overrides: ScruTable
Overridden by: OffsetImmuTable

with: other

Please use ImmuTable::combineWith instead. 'with' was an innapropriate name
because its use elsewhere (see ImmuSet::with and XuRegion::with) implies that
the argument is a single element to be added, not a collection of elements to
be added.

without: index

Return a new table just like the current one except with the association whose
key is 'index'.

Overridden by: ImmuTableOnMu OffsetImmuTable

Index - All Packages - All Categories - All Classes