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
and so @param tags just match up to parameters based on order.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5364 542714f4-19e9-0310-aa3c-eee0fc999fb1
- We use the ASC compiler, which works quite differently from compc/mxmlc. It doesn't attempt any mapping between class hierarchy and directory structure. You feed it source, that's it. This compiler is under continuous development, and the one shipped in Flex SDK 3 is buggy, so we supply our own in lib/asc.jar for the time being.
- Since much of Narya relies on classes that don't exist on Tamarin (e.g. DisplayObject), we have to isolate a specific subset of source. Right now that's done ridiculously explicitly as a list of class files, in etc/asc-files.txt. In the long run we will want to resolve this more elegantly, but there are no trivial solutions at hand.
- We have not implemented the full flash.utils.describeType() for Tamarin, but rather a subset of its functionality: one method to see if one type derives from another, and another method to extract the public variable names in an object. The environment-specific code has been isolated to com.threerings.util.env.Environment, and build.xml simply copies either Environment.as-tm or Environment.as-fp into place depending on what it's targeting.
- The ASC compilation links against lib/builtin.abc, which supplies information about core classes such as Object, Array, etc, and lib/thane.abc which is our homegrown emulation library containing e.g. flash.net.Socket and other things we need that's not part of the open-source code Adobe donated to Mozilla, but rather still in their proprietary Flash Player code.
I'm committing thane.abc and builtin.abc directly now, but they will shortly be built by the Thane project and published as maven whatnots. We could auto-publish lib/asc.jar too, but I think we may want more explicit control over how we version that.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5045 542714f4-19e9-0310-aa3c-eee0fc999fb1
Use it in SimpleStreamableObject's toString(), with some new formatting.
Unfortunately, the order of public variables seems random.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4746 542714f4-19e9-0310-aa3c-eee0fc999fb1
which parses a String like " 7pigs" as the value 7.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4723 542714f4-19e9-0310-aa3c-eee0fc999fb1
I'm not sure what I was thinking: we'll never want to auto-recognize
command:// urls in text. In the places where we'll use them we'll
format things ourselves.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4719 542714f4-19e9-0310-aa3c-eee0fc999fb1
Sigh. So not standard.
I suppose I could devise a whole system for registering protocols, and
adding registered protocols to this regexp, but we'll never have another
one of these and this is just easier for now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4709 542714f4-19e9-0310-aa3c-eee0fc999fb1
It's not needed, as the 'int' class has various formatting functions.
These functions can even be called on constants, if you trick the compiler
a little bit by wrapping them in parens:
trace("hex: " + (4097).toString(16));
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4522 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
- started making chat UI stuff
- upgraded SimpleMap some to use the new Dictionary class
- Lots of experimenting with attaching functions to interface implementations.
I've upgraded to the new beta of Flex and it's giving me the pain. There's
new compiler bugs and I am working blind right now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3966 542714f4-19e9-0310-aa3c-eee0fc999fb1