|
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 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 |
--[[ A generic pool to contain "active" and "free" objects. Active objects are typically objects which: 1. Have a relatively high construction cost 2. Are not lightweight enough to create many of them at once 3. Tend to be reused as dynamic elements of a larger container. The pool should "rapidly" reach a high-water mark of contained objects which should flow between active and free states on a regular basis. Ideal uses of the ZO_ObjectPool would be to contain objects such as: 1. Scrolling combat text 2. Tracked quests 3. Buff icons The pools are not intended to be used to track a dynamic set of contained objects whose membership grows to a predetermined size. As such, do NOT use the pool to track: 1. Inventory slots 2. Action buttons (unless creating something like AutoBar) A common usage pattern is instantiating templated controls. To facilitate this without bloating your own code you should use ZO_ObjectPool_CreateControl which has been written here as a convenience. It creates a control named "template"..id where id is an arbitrary value that will not conflict with other generated id's. If your system depends on having well-known names for controls, you should not use the convenience function.--]]function ZO_ObjectPool:Initialize(factoryFunctionOrObjectClass, resetFunction, usePooledObjectWrapper) self.m_NextControlId = 0 -- Just in case the user would like the pool to generate id-based control suffixesend-- Indicates whether pooled objects should have the ZO_PooledObject interface applied to them,-- allowing the use of object:ReleaseObject() to release them back to the object pool.end-- Defines whether pooled objects should implement the ZO_PooledObject interface.end-- Defines the primary factory behavior else self.m_Factory = function(pool, objectKey) return factoryFunctionOrObjectClass:New(pool, objectKey) end endend-- Defines the primary reset behaviorend if freeKey == nil or object == nil then return nextPotentialFree, nil end return freeKey, objectendendendendendendendendend local objects = {}end self.customAcquireBehavior = customAcquireBehavior -- Signature: function(objectBeingAcquired, objectKey)end-- Optional supplementary behavior that can be run after the factory has created the object-- Often used in conjunction with extension pool classes (e.g.: ZO_ControlPool) when you want all the default factory behavior, plus something extra self.customFactoryBehavior = customFactoryBehavior -- Signature: function(objectBeingCreated, objectKey, ZO_ObjectPool)end-- Optional supplementary behavior that can be run after the primary reset function has been run on the object-- Often used in conjunction with extension pool classes (e.g.: ZO_ControlPool) when you want all the default reset behavior, plus something extraend -- If the object referred to by this key is already -- active there is very little work to do...just return it. if object then return object, objectKey end -- If we know the key that we want, use that object first, otherwise just return the first object from the free pool -- A nil objectKey means that the caller doesn't care about tracking unique keys for these objects, or that the keys -- the system uses can't directly be used to look up the data. Just manage them with pool-generated id's if objectKey == nil then else end -- -- If the object is valid it was reclaimed from the free list, otherwise it needs to be created. -- Creation uses the m_Factory member which receives this pool as its only argument. -- Either way, after this, object must be non-nil -- if object then else end end return object, objectKeyend -- Apply the ZO_PooledObject interface to the new object instance -- to allow the use of the :ReleaseObject() convenience method. end end return objectend if object then endend end end end endendend endend return CreateControlFromVirtual(templateName, parentControl, templateName, objectPool:GetNextControlId())endendendendend--[[ ZO_PooledObject Abstract Class Helper class that allows pooled objects to be released more conveniently through the use of an added :ReleaseObject() method. To automatically apply this interface to objects in an object pool: local USE_POOLED_OBJECT_WRAPPER = true local myObjectPool = ZO_ObjectPool:New(myClass, ZO_ObjectPool_DefaultResetObject, USE_POOLED_OBJECT_WRAPPER) or local myControlPool = ZO_ControlPool:New("MyVirtualControl", myParentControl) myControlPool:SetUsePooledObjectWrapper(true)--]]ZO_PooledObject_Mixin = {}endend-- Static method-- Adds object pool support to an existing object.end |