2290
|
|
|
exarkun |
16 years ago
|
|
|
2289
|
|
|
glyph |
16 years ago
|
|
|
2288
|
|
|
exarkun |
16 years ago
|
|
|
2287
|
|
|
moe |
16 years ago
|
|
|
2286
|
|
|
moe |
16 years ago
|
|
|
2285
|
|
|
washort |
16 years ago
|
|
|
2284
|
|
|
moe |
16 years ago
|
|
|
2283
|
|
|
exarkun |
16 years ago
|
|
|
2282
|
|
|
exarkun |
16 years ago
|
|
|
2281
|
|
|
moe |
16 years ago
|
|
|
2280
|
|
|
exarkun |
16 years ago
|
|
|
2279
|
|
|
exarkun |
16 years ago
|
|
|
2278
|
|
|
exarkun |
16 years ago
|
|
|
2277
|
|
|
exarkun |
16 years ago
|
|
|
2276
|
|
|
exarkun |
16 years ago
|
|
|
2275
|
|
|
washort |
16 years ago
|
|
|
2274
|
|
|
washort |
16 years ago
|
|
|
2273
|
|
Allow shared functionality to be externally defined.
Author: glyph
Reviewer: exarkun
Fixes #2227
Previously, if you shared an object, only interfaces directly implemented by that object would be shared.
However, sometimes interesting functionality (as in the Blendix person / Mantissa person division) resides outside the item itself. It is now possible to control access to that functionality using the sharing system.
If you define an Item X, and then an interface, IY, and an adapter from X to IY, Xy, you may share IY from an X, and the object returned from getShare() for the X's shareID will use the IY method implementations from Xy to provide IY. Now, let's say you have a view adapter, V, which adapts IY to IV. The V (view) has access to a proxied, restricted Xy; the Xy (model layer 2) has unrestricted access to the X (model layer 1).
It makes sense if you think about it though, really.
|
glyph |
16 years ago
|
|
|
2272
|
|
|
glyph |
16 years ago
|
|
|
2271
|
|
|
exarkun |
16 years ago
|
|
|