Doing a loop on a null object works:
for (s in null)
But checking to see if a property is in a null object throws an error:
(s in null)
They're so similar!
So, protect against the NPE.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5233 542714f4-19e9-0310-aa3c-eee0fc999fb1
So broken! The XML class is not specified in the ECMA-262 standard.
Now I know why they needed the guidelines of ECMAscript: when left
to their own devices they design broken-ass shit.
Adobe needs a cork on their fork.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4932 542714f4-19e9-0310-aa3c-eee0fc999fb1
in an initObject. This is a fairly common practice in flash and let's go ahead
and use it sometimes, even though it's prone to runtime errors.
Our version of this has a defaults Object as well as another Object that can be
specified to mask properties from the initObject.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4908 542714f4-19e9-0310-aa3c-eee0fc999fb1
In java, if you override a varargs method you can easily call super, you just
have to do a wee cast:
@Override
public Stuff getStuff (int thing, Object... args)
{
return super.getStuff(thing, (Object[]) args);
}
In abjectscript:
override public function getStuff (thing :int, ... args) :Stuff
{
// This doesn't work, because now 'args' to super is an array
// containing OUR args array as its first element.
return super.getStuff(thing, args);
// We can fix things for super by 'apply'ing the function to
// all the args in one array...
args.unshift(thing);
return super.apply(this, args);
// But it could also be the case that someone is intentionally
// passing an array to this method (many flash library methods take
// varargs but also accept arrays and do this same thing).
if (args.length == 1 && (args[0] is Array)) {
args = (args[0] as Array);
}
return super.getStuff(thing, args); // super must ALSO do the unjimmying
// OR, we could combine the two so that super doesn't have to
// do unjimmying.
}
As a note, there is an 'arguments' object that is secretly placed in every
function call, presumably so that callers can test whether an arg is
the default value because the user didn't pass it in or whether it's
the default because the user happened to pass in the default.
Guess yourself, because that doesn't seem worth adding as a language feature.
Anyway, the 'arguments' is not an array! You can't use it to call super
via 'apply'. It's another associative hash. God bless you actionscript,
you just make so much fucking sense.
So I made a utility method for unfucking vargs.
I bitch a lot, yes, but my bitching takes only a fraction of the time
that was wasted discovering whatever it is I'm bitching about
(this was fun to trace backwards to the source, oh yes), and maybe I
can save others some time as a result.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4477 542714f4-19e9-0310-aa3c-eee0fc999fb1
InvocationRegistration had a constructor called Registration. I wonder if
that was causing the compile error with beta2.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4104 542714f4-19e9-0310-aa3c-eee0fc999fb1
- There seems to be a compiler bug that causes classes to be
imported spuriously, or something. Classes that import only one of the Log
classes are complaining about visibility of more than one of them.
- static constants are not inherited by subclasses, which is super annoying.
I will try switching to prototype consts, but there seems to be a problem
initializing those, and we don't want to make them vars...
- The fact that there are no inner classes combined with no method overloading
is making things very inconvenient. I've been experimenting with faking
an anonymous class by instantiating a dynamic object and attaching
functions to it, but it's not working. I'll continue experimenting, because
if we can't do this then someone shoot me.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3957 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell