While reflecting on the matter of deleting objects from the
timeoutList, I posed this question to myself: what if I wanted
to delete a subset of items from a list in the case I knew
their position _prior_ to having them deleted?
E.g. I want to delete the items number 3, 5, 8 from a list
of 10 items. Once the item 3 has been deleted, the item 5 became
4 and the item 8 became 7. So this sequence of calls:
linearList.deleteAt(3)
linearList.deleteAt(5)
linearList.deleteAt(8)
would cause one right deletion and two wrong ones.
I post here this handler that accomplishes the task:
on deleteSubset(<items>, <itemsToDelete>)
where <items> is a linear list of items of any type and
<itemsToDelete> is a valid linear list of indexes defining a
subset of items to delete from <items>. The handler returns
the number of items left into <items>. See below an example.
on startMovie
-- Fill a list with 10 items
metals = []
metals[1] = "tin"
metals[2] = "zinc"
metals[3] = "iron"
metals[4] = "silver"
metals[5] = "copper"
metals[6] = "lead"
metals[7] = "gold"
metals[8] = "platinum"
metals[9] = "titanium"
metals[10] = "aluminium"
-- Define a list of indexes of items to delete from metals[]
metalsToDel = [1, 4, 5, 6, 9, 10]
-- Delete and display the result
itemsLeft = deleteSubset(metals, metalsToDel)
put metals -- ["zinc", "iron", "gold", "platinum"]
put itemsLeft -- 4
end
on deleteSubset items, itemsToDelete
icnt = items.count()
dcnt = itemsToDelete.count()
i = 0
j = 0
repeat with i = 1 to dcnt
k = itemsToDelete[i]
items.deleteAt(k - j)
j = j + 1 - (k = icnt)
end repeat
return items.count()
end
-----------
Notation: when the formal parameter <items> receives the
actual value 'metals', the local variable set up to hold
this value points to the same memory location as 'metals'.
Hence 'metals' gets updated by reference from inside the
handler through this variable. This seems an exception in
respect with the normal behaviour of Lingo by which variables
are passed by value.
------------
The handler is so simple due to some basic limitations on
the parameter <itemsToDelete>. In particular, it can't:
- contain unsorted elements. If some code exist for
dinamically building <itemsToDelete> by adding elements
in whatsoever order, referring to the call of the example
above it should be replaced with:
itemsLeft = deleteSubset(metals, metalsToDel.sort())
Handling an unsorted list would require to set up a
temporary storage as large at least as itemsToDelete.count(),
so I wouldn't see any advantage in the use of it, compared
with the execution speed of the native .sort().
- contain the same element twice or more. In the case,
deleteSubset can be updated to face this occurrence,
but I didn't it for sake of simplicity.
- manage out-of-range or invalid indexes whether they
have been added to <itemsToDelete>.
A last observation. Due to the nature of the above example,
that uses names of metals for sake of clarity, it could be
expected that once given a subset of names of metals, like
["iron", "copper", "lead"], these items got deleted from the
main list. This is possible but it's a different task, or I
should say trend, in so far as it requires searching, that's
getting the keynames position into the main list.
Kind regards,
Franco
IFC Programming Consultant
http://www.chnexus.com/main.htm
Private mailto:[EMAIL PROTECTED]
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
