I'm not convinced yet. I try to follow the standard credo of
(academic?) PL designers: implement a minimal core with code extension
hooks and let programmers add what they need. No one has ever asked for
this feature before, and it's not clear that it's nearly fundamental.
On 08/28/2016 08:50 PM, Saulo Araujo wrote:
If I may, I'd like to advocate for a solution closer to the one that I
have prototyped. I still believe the rpcCount source should be part of
the standard library and that the rpc function should update the
rpcCount source. Suppose, for example, that I am using a module that
someone other than me developed and this module invokes the function
rpc. If the rpc function updates the rpcCount source, my application
would be able to show the busy indicator, which would not be true in
this other solution.
But there's another story that shows why it's an /advantage/ not to be
able to detect the RPCs in other modules: encapsulation. Library authors
want to be able to write code that hides details of exactly what is
going on. When you upgrade a library, you may find different RPC-count
behavior, which would be like being able to detect that a dictionary
class had gone from using hash tables to using binary search trees.
I think this really is a serious usability issue. In your original
example, what happens when your program is using a library that, between
versions, starts making more RPCs, so your UI says that "your" code is
"still working" when actually it's an expensive RPC in a library?
To me, it makes more sense to have a library defining a concept of RPC
groups, with special calls to make RPCs given groups as parameters.
Isn't it also nice to be able to measure separate categories of RPCs
separately?
To add such behavior on top of existing Ur/Web code, you just need to
redefine the identifier [rpc] at the top of a file, which could be
accomplished by [open]ing a library module.
In any case, this other solution made me think that maybe what we need
in Ur/Web is something like the HTTP interceptors of AngularJS (look
for interceptors in https://docs.angularjs.org/api/ng/service/$http).
In general terms, AngularJS allows one to register one or more
listeners/observers that it calls whenever it is about to make a HTTP
request and when it receives a HTTP response. This design is very
general, allowing any kind of behavior related to HTTP requests to be
plugged in, even in code developed by a third party. However, I am not
sure if/how this fits in the pure world of Ur/Web.
I have essentially the same worries about this idea: (1) as no one has
asked for it before, I'm not convinced that it's fundamental enough to
belong in the core; (2) it's hard to do without breaking encapsulation,
which I care about more than "convenience" in adding nonstandard
semantics to standard operations (which is /less/ convenient for all the
folks out there reasoning about their code and what it used to do vs.
what it does now!).
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
