obtain containment and a stack of specifically typed outer class references to
accomplish what we need without misleading casts.
This will require changes to Yohoho which I shall make forthwith.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6320 542714f4-19e9-0310-aa3c-eee0fc999fb1
1. CrowdPermissionPolicy is an object that lives inside a BodyObject, thus it
cannot use server services like dependency injection, nor BodyLocator. However,
that's not a problem because it will never be used by a ClientObject that is
not a BodyObject. If there were a way to enforce with parameterized types that
it only ever be used in conjunction with a BodyObject, I'd do that, but
parallel inheritance hierarchies are not something that any OO type system I'm
aware of can reason about.
2. ClientResolver and its children are not singletons. One is created for each
client resolution process.
I have certainly fallen prey to the same errors during enthusiastic reactions:
it looks like a rose, it has thorns like a rose, oh wait, it's a blackberry.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6319 542714f4-19e9-0310-aa3c-eee0fc999fb1
from BodyObject, then it's your responsibility to make sure that your
BodyObject carries your Crowd permissions. Checking the ClientObject for your
Crowd permissions and then using those on your (separate) BodyObject is too
weird.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6318 542714f4-19e9-0310-aa3c-eee0fc999fb1
This client-side commit matches the new BodyLocator.forClient() method on the server by the addition of CrowdClient.bodyOf(), which should be subclassed by anyone who wants to do anything fancy.
The default implementation is just for the client to cast itself to BodyObject, matching the default (and historical) implementation in BodyLocator.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6317 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Rename PrefixServer.Module classes to PrefixModule. They all implement guice's Module, and it's
hard to pass a class around as its interface if they share a name.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6303 542714f4-19e9-0310-aa3c-eee0fc999fb1
errors with duplicate receiver entries on reconnect in Spiral Knights, and
I'm hoping this will fix them.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6301 542714f4-19e9-0310-aa3c-eee0fc999fb1
the real source code. That's where reusable classes live. Amazing!
Also cleaned up some build.xml bits and nixed the Retroweaver stuff. I thought
we might have still been using that, but then I saw the hardcoded path to
/usr/local/jdk1.4 and knew that it couldn't be so.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6285 542714f4-19e9-0310-aa3c-eee0fc999fb1
tasks are, so let's split out the generation of C++ streamable classes into a
genstream class rather than letting it run on the build server which causes
breakage like just now when Ray changed something that caused differently
generated C++ streamable classes to be generated on build1.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6280 542714f4-19e9-0310-aa3c-eee0fc999fb1
closer to working. Firstly, we need to not skip the asdoc build if the aslib
build happens to have generated an up to date .swc. Second, asdoc needs to know
about our library dependencies. Third, we need not to tell it to look for
sources in the non-existent src/player directory.
It's still failing, claiming:
[java]src/as/com/threerings/presents/util/SafeObjectManager.as(30):
col: 37 Error: Definition com.threerings.presents.dobj:SubscriberAdapter
could not be found.
[java]
[java] import com.threerings.presents.dobj.SubscriberAdapter;
which is nonsensical. If it can find SafeObjectManager to try to generate
documentation for it, then it can damned well find SubscriberAdapter which is
also part of this project. SubscriberAdapter depends on no other classes
itself, so it can't be a problem with a dependency of SubscriberAdapter.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6279 542714f4-19e9-0310-aa3c-eee0fc999fb1
The big win is that getKey() now exists on each of those event types.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6278 542714f4-19e9-0310-aa3c-eee0fc999fb1
Andrzej Kapolka