1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
|
TODO:
- copy functions
- automatic coercion for hash[ x , ... ] where x is a 'name'
- invert not working correctly
- ha2 <- ha[] : should produce copy and not a reference?
- Is there a happly function that is like lapply that either passes keys and
values to the functions happly( h, function(k,v,...) ), will it return a hash
object?
- Increase perfomance of `[` and `hash` methods
- Be able to create a loop that assigns both key and value, e.g.:
for( k,v in ha ) ...
- (LOW PRIORITY) default MISSING behavior should be customizable at the hash
instance level.
Requires a slot: @na.action that can be a function or value. This default
should exist between the global default and the call level.
This is low priority since missing customization only applies to hash slices
now.
- Default of missing key should be NULL.
- option to fail on missing key?
- customizable missing
- Should the default value of non-existant keys be NA or NULL.
- The default of the environemnet is NULL
- NA is the norm when data is missing, i.e. from a frame.
l:: THUSFAR, we are using NA when there are missing keys.
- N.B. When access these objects the missing values are returned:
- vectors : NA
- list : NULL
- data.frames : NULL
- since getOption( 'na.action.hash' ) returns NULL if undefined, we can
use this as getOption( 'na.action.hash' ) as the na.action only . . .
but this sets the value of the Hash to NULL. Setting the value to NULL
is equal to deleting the key. h$key <- NULL deletes the key. So we should
have no.
- NA is retu
- Handle any type for a key, especially integers.
- Keep track of the type of the key: hash@key.class
- Show method should sort on key or use: hash@indexed
x make.key already uses as.character
- Would require that there be a way to turn that value into a scalar perhaps
even through the make.key or make.name functions.
? Do we allow mixing of types ? :: NO
- See also IxHash TODO below.
- x <- h ; produce x as a reference to h and not a copied object.
- IxHash : Indexed Hash. Allow access by integer position?
There becomes a problem of keeping track of replacements.
- Implement Judy Hash?
- Is there a abstract version of the hash where keys can contain muliple values?
how would this be implemented as an md5hash of the args?
h[[ vector ]] <- values ?
h[[ paste( as.character( vector ) ) ]] <- value
How can we make each of the keys searchable? i.e. get all where the second
key field = 7. Each of the key fields would have to be hashed?
- Coersion functions
- as.vector,
- pairlist,
- as.data.frame,
x as.environment,
x as.list
- other coercions :
as.environment, not possible without clobbering base h@env anyhow
as.data.frame, yes
as.vector , yes
- Implement clear as initializing of hash rather than rm
- R/clear.R bug? :: SHOULD THIS COPY THE HASH?
h <- hash( letters, 1:26 )
hh <- h
clear(hh)
h # EMPTY.
Does not work the same with 'rm'. Will this require overloading the
assignment operators?
- test functions
x is.hash : object is a hash
is.vector : test values to see if they are expressible as a vector
is.list : "
- assign <==> set : it is to bad that assign is used instead of get
get/set seems better aligned than get/assign.
============================ COMPLETED ================================
x copy method: copy( hash )
x is.empty method?
h <- hash()
is.empty(h) # TRUE
x Move functions to their own file . . . hash.actions
x implement max.print.
x DEPRECATE $
x DEPRECATE: .get use get and mget instead to create [ and [[ and use these instead
X implement length as env.profile(ha)$nchains? No. Not the same result.
x mget.hash
- is it faster than sapply(x, function(x,hash) hash[[x]], hash )?
x test for missing keys for accessor ($, [[, [)
x emits NA
x $, [[
x [ : what is the behaviour of trying to access a missing key among many missing
keys.
x GET
x consider eliminating .get :: NO
x mget : return ... override base::mget :: decided values works better
x values :
x There is an ambiguity of whether to simplify or not
x move @env to @.Data
NO- move @.Data to plain object: this should be explicit.
x inverted.hash constructor function to directly create an inverted hash
x Constructor method should handle hash and environment objects.
what does hash( hash() ) give? A ref to the hash.
x Get rm working correctly so that a call to clear is not needed before
the call: I do not think this is necessary any longer.
to rm. See the bookmarked link of how this is managed. Detach?
x 'delete' as an alias for del to match Perl dictionary lingo.
x Modify arguments to 'hash' to be named ( x, key, value ) ?
( x , value )? (...) and pass the lot to set()? And let set sort it out?
- Generics:
x set : can this be replaced by [ or [[
x get : "
we can probably get rid of get, set but will need to create them as
hidden functions in the hash package: hash::get and hash::set
x Should
x h[[key]] <- NULL
x h[, key] <- NULL
x h$key <- NULL
x erase the items as it does for data.frames? Yes.
x items : as.list
this is a base function. The methods should closely mirror the base
function.
x length : needed (keep)
x keys : same as names?
x values : [] [[]]
x del : same as rm -- see items 1 and 2 above
x clear : same as new
x show :
has-key: same as exists
summary: create
x methods: [[ [ $ keys values( no different from accessors )
x del clear show has.key show
x remove : items, set, get
x - if we remove set and get as methods ... then we should have them
x as functions in the class.
x how many accessors do we need? get, values, $, [, [[ .
get and values are essensially the same.
What about values(h) <- x?
or keys(h) <- x
should these be viable replacement functions as well?
x How do we use set to accomodate setting from data.frame? list? environment?
and hashes? append( hash, list or data.frame or env or hash ) to add
Then we have to be more explicit ... h[[keys]] <- values etc.
x what about
x names(h) ?
x ls(h) ? Cannot be done.
there is a potential problems as both names and ls might imply that there is
an order to the hash which there might not be.
x Rename slot x to .env.
Although a class cannot inherit from 'environment'
If we name the environment slot .Data, we cannot set it with the constructor
'new'. Calling new( "hash", .Data = new.env( ... ) result in the following
warning ...
Error in initialize(value, ...) :
initialize method returned an object of class "environment" instead of
the required class "foo"
The object is then class environment.
Other option call the slot 'env' or 'Data' or 'hash'
'.Data' cannot be set.
So we have:
h@hash, x@hash, hash@hash
h@env, x@env, hash@env
h@data, x@data, hash@data
Personally I like env. hash is too generic and confusing. data is too generic
|
