| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we've done more refactoring, it's no longer necessary to
have this machinery, since:
* We can support statically registering instantiated methods, if we
know them ahead of time.
* Writing an installer function is pretty simple, and the syntax
is much nicer than the special-purpose junk we had before.
I've added examples of both approaches.
While we're at it, I've simplified the syntax for `invoker_ent!` a
little, since the parentheses I had before aren't necessary.
|
| |
|
|
|
| |
These are no longer needed, since they are inferred from the types
of the functions.
|
| |
|
|
|
|
|
|
|
| |
The trick here is to provide an `Invoker` trait,
with blanket implementations for appropriate `fn(_,_,_,_?) -> _`.
With this trick, we no longer need to have a `decl_rpc_invoke_fn`.
This lets us discard HasConstTypeId entirely,
and will let us simplify some other syntax moving forward.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Since we can't enumerate every instantiation at compile time,
we instead provide a macro to generate an _installer_ function
that installs a set of functions for a given instantiation.
Due to the limitations of macro_rules, the syntax for generics is
a bit ugly.
|
| |
|
|
|
| |
Now there is an `decl_rpc_invoke_fn` macro that *only* declares the
type-erased functions. Another macro's job will be to register it.
|
| |
|
|
|
|
|
|
| |
This will be called _static_ to make it clear that it registers the
method statically, so you don't need to install it at runtime.
After a bit more work, there will be a separate macro that declares
an installer function.
|
| |
|
|
|
|
|
|
|
| |
We don't actually need this to be a trait; we just need
methods and objects to have a `CONST_TYPE_ID_` if they want to
participate in the inventory-based method registry.
Removing this trait makes it much simpler to declare methods and
objects.
|
| |
|
|
|
|
| |
This simplifies our implementation logic in a few places,
and simplifies our invocation syntax greatly. There are a few
infelicities, noted in `TODO RPC` comments.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a rather tricky piece of functionality. It works as
follows.
We introduce a `CastTable` type. Each `CastTable` tells us how to
downcast `dyn Object` for objects of a single concrete type.
The `Object` type now has a `get_casttable` method that returns
an empty `CastTable` by default.
`CastTable` is, internally, a map from the `TypeId` of the target
dyn Trait reference type to a function
`fn(&dyn Object) -> &dyn Trait`. These functions are stored as
`Box<dyn Any + ...>`. (They are Boxed because they may refer to
generic functions, which you can't get a static reference to,
and they're Any because the functions have different types.)
The `decl_object!` macro now implements `get_casttable` as
appropriate. (The syntax is a bit janky, but that's what we get
for not using derive_adhoc.) For non-generic types, `get_casttable`
uses a Lazy<CastTable>`. to initialize a CastTable exactly once.
For generic types, it use a `Lazy<RwLock<HashMap<..>>` to
build one CastTable per instantiation of the generic type.
This could probably be optimized a bit more, the yaks could be
shaved in a more scintillating hairstyle, and the syntax for
generic `decl_object` could definitely be improved.
|
| | |
|
| |
|
|
|
|
|
| |
Rationale: Our weak-vs-strong design is a bit confused at the moment
due to concerns about deduplication and capability semantics. It's
not clear that a general "change strong to weak" method is
compatible with what we want to provide.
|
| |
|
|
|
|
|
|
|
|
|
| |
I've made doing some design choices here:
* Reserving "rpc" as a prefix for post-authentication
functionality that is not arti-specific.
* Declaring these to be methods on the session rather than methods
on the objects themselves.
There's a problem with defining an API to drop a weak reference; see
comment in code.
|
| | |
|
| |
|
|
|
| |
Now you just declare your function `my_func` with the right types,
and invoke `rpc_invoke_fn!{ my_func(ObjType, MethodType); }`
|
| | |
|
| | |
|
| |
|
|
| |
This lets us do much less in our rpc_invoke_fn functions.
|
| |
|
|
|
| |
Now `Method` has an Output and Update associated type, and
`decl_method` can do a little more.
|
| |
|
|
|
| |
Previously we have two places where we had to do "make a `Drain` sink
if updates aren't wanted"; now there's only one.
|
| |
|
|
|
|
|
|
| |
Now that the sink is not part of the context, RPC functions that are
able to send an update have to declare an `impl Sink` as their
fourth argument. This syntax is not final.
Part of #824.
|
| |
|
|
|
| |
Now the update sink is its own boxed object. It is not yet passed
to the invoke functions that want it.
|
| | |
|
| | |
|
| | |
|
| |
|
