- handle // @Override // blah style comments
- deal with fields that are assigned to anonymous inner classes (actually
anything with braces, which would also include array literals).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4667 542714f4-19e9-0310-aa3c-eee0fc999fb1
(ByteArray is a special class for dealing with bytes. It does not extend
the normal Array).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4452 542714f4-19e9-0310-aa3c-eee0fc999fb1
an arbitrary Java class which we are converting to ActionScript (the language,
not the class). Hopefully this will appease the compiler.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4419 542714f4-19e9-0310-aa3c-eee0fc999fb1
aren't magically in scope for ActionScript, we have to generate import
statements for them.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4414 542714f4-19e9-0310-aa3c-eee0fc999fb1
when we encounter the pattern "new SomeClass[0]". Le whee!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4410 542714f4-19e9-0310-aa3c-eee0fc999fb1
field/method names for the ActionScript version of a class (or to omit
something entirely). This removes the need for special case hackery for
toStringBuilder().
In order for annotations to work, however, we have to require that the
GenActionScriptTask be loaded from the same classloader that loads the classes
to be reflected upon. Before we only reflected on the target classes, never
instantiated them. Annotations are actually instantiated, so we have to be able
to create an instance of the ActionScript.class that is compiled into our
target classes and assign it to a reference that is compiled into
GenActionScriptTask. Beware the complexities of dealing with multiple class
loaders.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4405 542714f4-19e9-0310-aa3c-eee0fc999fb1
because we can't do that in ActionScript; properly handle static var and
non-static const.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4404 542714f4-19e9-0310-aa3c-eee0fc999fb1
interfaces, and Marshallers for same. The remaining snag has to do with the
annoyance of ActionScript not supporting inner classes, which means that
ChatService.TellListener for example has to become ChatService_TellListener.
The code for generating the Java marshaller knows to add an import for
ChatService if some random invocation service interface happens to reference
ChatService.TellListener, but now it needs to be made to know to add an import
for ChatService_TellListener in ActionScript land and it has to do it in a way
that doesn't fuck up the Java code generation. Whee!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4397 542714f4-19e9-0310-aa3c-eee0fc999fb1
Java. Of course this is a very limited translation facility that is mainly
focused on auto-generating Streamable ActionScript classes from their Java
originals, and it doesn't actually convert method bodies, just field and method
declarations, initial values, and such.
Most of our Streamable classes don't have much in the way of real methods, and
the autogenerator will stick new methods in when they show up on the Java side
so at least we'll *know* that they need to be implemented. And the main thing:
readObject and writeObject are in fact implemented by the code generator so at
least we won't be plagued by annoying streaming errors when we change something
on the Java side and forget to change the ActionScript side.
Next up, auto-generating InvocationService interfaces and InvocationMarshaller
implementations in ActionScript and ActionScript versions of DObjects.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4394 542714f4-19e9-0310-aa3c-eee0fc999fb1
unmarshalled into an ArrayList on the receiver. Along the way, I improved
support for generic types as arguments to invocation services (which required
one unfortunate "sweeping" warning suppression, but since this is in generated
code, I think we can be sure it won't be doing anything untoward).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4375 542714f4-19e9-0310-aa3c-eee0fc999fb1
required some serious bending and folding of the generic type system, but for
the most part we managed to avoid any mutilating. The gendobj task now
generates properly typed "addToXXX" and "updateXXX" DSet methods based on the
parameterized type of the DSet. This might cause unrecompiled code to break,
but I don't think there are many cases in the base toolkit where people call
DSet adders or updaters. We'll see and I'll add backwards compatibility
versions for cases where we need them to support GG games (everything else we
can just recompile).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4245 542714f4-19e9-0310-aa3c-eee0fc999fb1
parameterized types will be easy to add, but I've not yet had occasion to use
them. We're all about "just in time" support.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4165 542714f4-19e9-0310-aa3c-eee0fc999fb1
These are the preferred way to get instances of Boolean, Byte,
Short, Character, Integer, Long, Float, and Double object.
It's always made sense for Boolean objects, and with 1.5 these factory
methods were blessed as the proper way to get instances unless one
absolutely needed a distinct object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4145 542714f4-19e9-0310-aa3c-eee0fc999fb1
genericize Narya data structures, nor make the existing code type safe. That's
going to be an extremely large project.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4007 542714f4-19e9-0310-aa3c-eee0fc999fb1
previously redone the InvocationService and DObject generation tools but not
the InvocationReceiver tool.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3913 542714f4-19e9-0310-aa3c-eee0fc999fb1
Have invocation marshallers track whether someone ever ended up responding
to the client: if they get garbage collected without ever doing so
(and they're not the base class InvocationMarshaller, which can only report
errors), log an informative error message.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3792 542714f4-19e9-0310-aa3c-eee0fc999fb1
not be generated. Cleaned up the generated provider interface formatting a bit.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3715 542714f4-19e9-0310-aa3c-eee0fc999fb1
and FooDispatcher. This means we will no longer be able to make FooProvider a
class that directly handles FooService methods, but the savings in confusion
for first time users of the framework will more than make up for the minor
inconvenience.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3714 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne