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
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
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
accomplish our "previous value" support in the distributed object system
without using reflection and could also avoid using reflection in the case
where we have already applied the event on the server (which is generally
the case on the server).
Rather than hacking up the gendobj script, I took this opportunity also to
rewrite the DObject generation script as an Ant task and in doing so,
implemented another recent idea which is that we can just augment the
FooObject.java file instead of having a separate .dobj and .java file.
You'd think it was spring there's so much cleaning going on.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3284 542714f4-19e9-0310-aa3c-eee0fc999fb1
Narya. I added directives to the compile line to prevent that from
happening again.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3247 542714f4-19e9-0310-aa3c-eee0fc999fb1
load the project's service classes so that they are comparable. Also sort
everything to avoid pointless changes in regenerated source files when
Java decides to arbitrarily return the methods in a different order.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3242 542714f4-19e9-0310-aa3c-eee0fc999fb1
GenReceiverTask (not yet implemented). Modified the task so that it can
load the service classes via a classpath declared inside ant, avoiding the
need to put project classes in Ant's classpath.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3240 542714f4-19e9-0310-aa3c-eee0fc999fb1
dispatching classes in Java to eliminate annoying dependency on the output
format of JDK 1.4.1's javap.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3238 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne