Hector, I'm afraid you lost me there. I'm always eager to improve my code,
but I am having trouble figuring out what you're talking about. I *think*
you were saying that the code promotes some bad coding habit having to do
with loop iteration, but I'm not sure what that could be. The only loop in
the code is a numeric for loop that iterates over an array.

I'm curious to know what you're referring to regarding the internal loop
counters and references and such. Maybe the easiest way to help me
understand would be if you could post a snippet of code that does things the
wrong way, to illustrate the problem you're talking about.

(I wonder if you were thinking of the message someone else posted suggesting
that a "for in" loop on a JS object would iterate the items in the order
they were inserted? There's no guarantee of that, which is the reason for
the keysByIndex array in my code.)

The bug in the code I posted is that the [].splice() calls change the
indices of existing entries in the keysByIndex array, which means that the
index properties in the itemsByKey items become invalid. There are several
ways that could be fixed; which is best would depend on the optimization
goals for the code. And that's where I committed a real software engineering
sin, which is not having clear requirements before coding. It was just an
off-the-cuff coding example, after all. :-)

FWIW, the assumptions I made were:

* There may be a large number of items in the cache.

* You want to be able to remove individual items as well as prune the oldest
items.

* When you prune the oldest items, you want it to be faster than it would be
to iterate over the entire collection (i.e. you may prune a small number of
the oldest items in a large collection).

If those last two items aren't requirements, the code could be much simpler.
Get rid of the keysByIndex array, and just put a sequence number in each
cache item. Keep track of the lowest sequence number currently in the cache.
To prune "n" of the oldest items, iterate over the entire cache, and delete
each item you find with a sequence number less than that lowest number plus
n. When done, update that saved lowest number.

It's also not hard to fix the code so it iterates over only the number of
items you want to prune. If you don't need a remove() method, it's very
easy: Simply get rid of the index property in each cache item. That's only
needed for remove(). If you do need a remove method, it can also be fixed
pretty easily, but now I'm getting way off topic... :-)

-Mike

> From: Pops
> 
> Hi Mike,
> 
> I didn't analyze your code, but as I said (or maybe I was 
> thinking of saying it but do not) is that JavaScript, to me, 
> a guy is extremely strict and high software quality 
> development practices, promotes bad coding habits.  I say 
> that because I have already caught myself doing stuff that I 
> would not otherwise just because javascripts allows it.
> 
> So in this case, the idea that the associated array for loop 
> interation is not ordered is reason enough not to bother with 
> any more with it. Even though, as you indicated and I believe 
> you, it is harmless and it is very tempting to use that 
> logic,  I just do not feel right it won't pull the rug from 
> under the feet of the internal loop counters or references in 
> various javascript RTEs.
> 
> So even though JS may allow it, from a design standpoint, to 
> me, it is bad practice to wrote code with this behavior 
> simply because it can carry over to other languages where it 
> will definitely be an run time error.  I am already fighting 
> global variables :-)  I'm trying to write code in JS like its 
> real OOPs language and its really not. :-)
> 
> I don't think it is off topic because anything that has to do with
> Javascript is related to jQuery.    In this thread, I was designing a
> cache for a jQuery plugin.  Also,  when I posted the original 
> message, I was also thinking that maybe someone would mention 
> jQuery's own makeArray and related ideas to see and/or 
> mention how jQuery maintains its own cache.
> 
> Anyway, are you really going to make use study your code to 
> see what was wrong with it? :-) just tell us. <g>

Reply via email to