Not available in Java, and generally a bad idea.
Pretend ordinal() doesn't exist, unless you're writing EnumSet, or something.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5858 542714f4-19e9-0310-aa3c-eee0fc999fb1
I did not add true() and false(), because WTF, YAGNI.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5810 542714f4-19e9-0310-aa3c-eee0fc999fb1
It's the closest thing to a shutdown.
I've got half a mind to write a LinkedHashMap, and then
an ExpiringHashMap on top of that, and then have
ExpiringHashSet just utilize that in its internals.
But, YAGNI, for now... for now...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5784 542714f4-19e9-0310-aa3c-eee0fc999fb1
- We shouldn't need to run checkTimer() on add(), generally.
If adding the sole element, we can just schedule the expiration
directly.
- Simplified and functionalized some other bits.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5778 542714f4-19e9-0310-aa3c-eee0fc999fb1
using the new varargs fanciness, including a stack trace from the error.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5762 542714f4-19e9-0310-aa3c-eee0fc999fb1
Now it is more useful for this to hash identically as in Java.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5753 542714f4-19e9-0310-aa3c-eee0fc999fb1
I'm not sure how much actual utility is here, and how much I just like the
gee-whiz factor.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5731 542714f4-19e9-0310-aa3c-eee0fc999fb1
I sorta want to make a new FunctionUtil so that I can use it
with impunity everwhere without having to include the other crap in here.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5730 542714f4-19e9-0310-aa3c-eee0fc999fb1
Tip from the pros: when you change a class, you might want to check
the subclasses for possible problems with that change.
:P
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5729 542714f4-19e9-0310-aa3c-eee0fc999fb1
Let's try it and see if it works. Let us know Nathan.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5728 542714f4-19e9-0310-aa3c-eee0fc999fb1
I hate your checkin comments, but I love your product!
The real reason I cleaned up HashMap: I override
forEach(), and now I don't need to do anything to make values() and keys()
work properly for weak values. Less code is better code.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5726 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Implement keys() and values() using forEach().
- Less code is better code.
- But, it's less efficient:
- values() now looks up simple-key values by hashing
- values() now unwraps non-simple keys, even though unneeded
- keys() looks up simple-key values, even though unneeded
Say it with me like a 14-year-old girl: whatEVER!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5724 542714f4-19e9-0310-aa3c-eee0fc999fb1
We could trash it and change our toStringBuf() methods
to just return a String. I guess. Then the caller would
have to assign the string somewhere. I guess this has some value.
So anyway: Occam's razor, and fixes a small bug: appending undefined
would print as "null" since it was being forced to an Object first.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5722 542714f4-19e9-0310-aa3c-eee0fc999fb1
Immediately after writing them I considered that they didn't
really belong in ArrayUtil, since they don't operate on Arrays.
Util is better, since it's less specific.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5686 542714f4-19e9-0310-aa3c-eee0fc999fb1
Hopefully nothing was setting the values.
If so, maybe we'll see compile-time errors/warnings.
Maybe.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5677 542714f4-19e9-0310-aa3c-eee0fc999fb1
test cases I've made, it just doesn't work in *other instances*,
which I haven't yet been able to control for.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5676 542714f4-19e9-0310-aa3c-eee0fc999fb1
Apparently they enhanced AMF3 encoding in flash 10. Dictionaries
seem to be encoded differently. I'm sure they thought that they
could sneak this in because it's backwards-compatible, but they
thought wrong. If a Flash 10 client encodes a Dictionary, it
can't be read by a flash 9 client because it's not forwards-compatible.
If you change the spec, you gotta change the version number, because
this shit might be persistent.
So: work around it. Might be sketchy. Let's keep an eye on it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5673 542714f4-19e9-0310-aa3c-eee0fc999fb1
preferences or just providing a runtime place for them to live.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5671 542714f4-19e9-0310-aa3c-eee0fc999fb1
If there's an error when calling the callback function,
we were assuming it was an argument-related error and trying again.
However, this is sorta bad behavior as we don't want to call
twice into a callback. In the case I was seeing, the first time
in caused an NPE, but popped up a panel, and the second try
was no-opping because the panel was already up (but misconfigured).
So: don't even try a second call, because it looks like
flash will accept args to an argless function.
We'll have to try this out for a while and see if it works.
If so, I can neaten this code. If not, I'll uncomment
some of this and try a more surgical approach (only catch
ArgumentError, only retry if we had 1 boolean arg.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5585 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell