because that will overwrite the hackery we do with _oldEntry. Oh hackery, how
we love you so.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6586 542714f4-19e9-0310-aa3c-eee0fc999fb1
breaks streaming. Everyone will have to regenerate their services. Sorry! If
only I hadn't hardcoded the insertion of the constructor in the first place,
this would have all been nicely behind an abstraction boundary. It will be once
the services are regenerated.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6584 542714f4-19e9-0310-aa3c-eee0fc999fb1
streamed property of the event. It turns out to be cleaner to just set it in
the places where we know that we want a specific transport anyway.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6581 542714f4-19e9-0310-aa3c-eee0fc999fb1
think that's probably just because we're used to it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6577 542714f4-19e9-0310-aa3c-eee0fc999fb1
unserializing, or a weird alternative code path in the main constructor when
unserializing.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6576 542714f4-19e9-0310-aa3c-eee0fc999fb1
various base classes. This allows us to use final fields in some cases, which
I've done (though our naughty penchant for mutation forced me to roll back a
bunch of other spots where I would have liked to make fields final).
This is going to break a few things in dependents, because said dependents will
have zero argument constructors of their own which will need to be removed.
I'll be tracking those down and cleaning them up as build failures provide me
with infos.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6575 542714f4-19e9-0310-aa3c-eee0fc999fb1
constructor with zero/null values and then overwrite any fields initialized
with them immediately afterward" approach. If a Streamable has a zero-args
constructor, that is still used, so all the existing Streamable classes will
still function exactly as before. But new classes (or old classes undergoing
scrutiny) can opt to reduce their boilerplate as long as they know they cope
with the zero/null-valued constructor call.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6573 542714f4-19e9-0310-aa3c-eee0fc999fb1
Also, add some @Overrides that were missing on things that were overriding a base class method.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6570 542714f4-19e9-0310-aa3c-eee0fc999fb1
If we /didn't/ care at all about backwards compatibility, my preferred approach would have been to have the invoker for PeerManager injected in the constructor instead of as a field such that said constructor could be overridden and the invoker be injected with a different annotation.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6569 542714f4-19e9-0310-aa3c-eee0fc999fb1
RFC. I realize I need to add a lot of examples to the documentation.
The biggest win here is only needing to learn the ins and outs of
this one class, and using it everywhere for your listening/chaining needs.
Please, let me know what you think.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6568 542714f4-19e9-0310-aa3c-eee0fc999fb1
wearing the camouflage of being an empty method body.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6564 542714f4-19e9-0310-aa3c-eee0fc999fb1
how we're going to stream a class and then create the right streamer for it.
Using the ClassStreamer for an interface and then not doing any of the
ClassStreamer stuff means: don't use a ClassStreamer.
I went in here intending to find or create a dummy Streamable streamer that
all interfaces could share...
But, as it turns out, non-final arrays don't need a delegate streamer, so I can
just remove that and interface types will never create a Streamer.
(Interfaces can never be final.)
So: the problem just goes away and everything gets cleaner.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6563 542714f4-19e9-0310-aa3c-eee0fc999fb1
classes that rely on the marshallers never being initialized don't break.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6560 542714f4-19e9-0310-aa3c-eee0fc999fb1
original source code did not list it as such:
- protected Name _user;
- @Inject ChatHistory _chatHistory;
- }
I wonder whether it worked...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6559 542714f4-19e9-0310-aa3c-eee0fc999fb1
improvement in locality of code and reduction in LOC.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6556 542714f4-19e9-0310-aa3c-eee0fc999fb1
We need to support legacy closures that have multiple constructors, one of
which will be a zero-argument constructor. All of the existing static inner
classes that extend NodeAction/NodeRequest will be such legacy classes. Whee!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6555 542714f4-19e9-0310-aa3c-eee0fc999fb1
synthetic val$local fields that get inserted, only the this$outer field. And we
need to pass "zero" values for val$ fields to the synthesized constructor.
This means that closures cannot have more than one constructor, but since
they're anonymous inner classes, they necessarily have only one constructor, so
we should be fine.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6552 542714f4-19e9-0310-aa3c-eee0fc999fb1
warning about having to extend them with static inner classes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6551 542714f4-19e9-0310-aa3c-eee0fc999fb1
streaming mechanism will quietly gloss over the funny little outer class
reference stuffed into your closure as long as you promise not to use it
(because it's going to be null on the other side of the wire).
This will allow us to write:
_peermgr.invokeNodeAction(new NodeAction() {
...
});
which we presently have a big fat warning against, since it didn't work until
about 30 seconds from now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6550 542714f4-19e9-0310-aa3c-eee0fc999fb1
from the beginning, but useful if you clear the profiles in order to record
over a brief interval).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6546 542714f4-19e9-0310-aa3c-eee0fc999fb1
having every node connect to every other, we want to support having (for
example) nodes connect to a "super-peer" that distributes updates to its
children.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6537 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne