<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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.<br>
<br>
On 08/28/2016 08:50 PM, Saulo Araujo wrote:<br>
<blockquote
cite="mid:CA+ckhoTuB8b=CNh9XMQ2orEmkXr9ZQn=RD_rWwMHCuNZjEZ3HQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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.</div>
</div>
</blockquote>
<br>
But there's another story that shows why it's an <i>advantage</i>
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.<br>
<br>
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?<br>
<br>
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?<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CA+ckhoTuB8b=CNh9XMQ2orEmkXr9ZQn=RD_rWwMHCuNZjEZ3HQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>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 <a
moz-do-not-send="true"
href="https://docs.angularjs.org/api/ng/service/$http"><a class="moz-txt-link-freetext" href="https://docs.angularjs.org/api/ng/service/$http">https://docs.angularjs.org/api/ng/service/$http</a></a>).
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.</div>
</div>
</div>
</blockquote>
<br>
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 <i>less</i>
convenient for all the folks out there reasoning about their code
and what it used to do vs. what it does now!).<br>
</body>
</html>