I just feel like: imagine if there were no Map.containsKey().
You would instead have to get() the value and see if it's not null.
If you did that, you certainly wouldn't throw away the value if you
were going to get it again right below, would you? So why would
you do it simply because of the addition of a convenient method
called containsKey()?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5067 542714f4-19e9-0310-aa3c-eee0fc999fb1
crowd was intentional (with presents on top because it is more "generic"). We
must resist Eclipse's desire to squish our imports together into one giant,
hard to (visually) parse blob.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5060 542714f4-19e9-0310-aa3c-eee0fc999fb1
* New directory tests/src/as with port of java test client
* New build target "abclib" to create a library of the test classes specified
in etc/asc_files.txt
* New target to compile TestClientMain.as against testslib.abc and another to
run it.
(This proposes the naming convention of *Main.as for "main" thane code and
main-*.abc for the compiled code)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5058 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Created concept of a pattern for transforming imports rather than have some
methods assume a suffix is provided and others assume a prefix
* Leave full array types in import set initially so that they can be dealt with
differently by different code exporters
* Added more primitive types and array types for action script marshallers,
including conversion to TypedArray
* Add listener marshaller mungings for action script marshallers' imports
* Added handling for array imports for action script services
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5048 542714f4-19e9-0310-aa3c-eee0fc999fb1
Maybe I'll screw around with passing properties down to sub-projects to
control their stack trace verbosity when I'm not sick.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5047 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
(I just noticed marshallers are importing themselves but the flash compiler
doesn't seem to mind, so committing now)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5043 542714f4-19e9-0310-aa3c-eee0fc999fb1
clean action script files with no unnecessary imports
* New class ImportSet to facilitate the operations being performed manually
throughout the code. Also removes the need for rawimports
* Threaded ImportSet through all places where imports and rawimports were used
and removed magic parameters to control import generation
* Added an ImportSet instance to ServiceListener, this was key to the action
script fixes
* Moved all the import tweaking and munging logic into the generate* methods
and made specific to code being generated (removed overreaching stuff
from ServiceMethod, this was part of the problem)
* Removed blanket imports from tmpl files
* Removed unused methods
* Fixed tabs from last commit
* Quick and dirty script to check for unused imports
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5041 542714f4-19e9-0310-aa3c-eee0fc999fb1
* ServiceMethod import options:
- Made argument type imports ignore first N args (0 for old behavior)
- Made marshaller listener imports optional
* Added InvocationTask._verbose and several dumps of current imports to help
track down future superfluous imports
* Made the import of ServiceListener method arguments' types optional
* Wrapped up most of processService code into protected inner class
ServiceDescription and made configurable:
- Optional import of the types of the first arguments of the service methods
- Optinoal import of the types of listener method arguments
* Changed generate methods to take the service class and construct their own
local ServiceDescription configured for their target
* Removed global import of service class and do it explicitly where required
(via method addServiceImport)
* Made some imports conditional
- InvocationResponseEvent for mashallers only if service has some listeners
- InvocationException for providers only if service has some methods with
listener arguments
* Removed unused variables and imports
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5036 542714f4-19e9-0310-aa3c-eee0fc999fb1
Jamie Doornbos