explicit locking is more error prone.

【 在 muser (负尽千重罪，练就不死心) 的大作中提到: 】
: 另外，在传统gui里，是通过锁定界面来防止运算过程中的数值改变。angular加个功能以指定某个时段内某dom节点disabled应该也很容易吧？
--
FROM 183.195.251.*

using locks means you are working with shared mutable state, which is
already bad up front.

if you want a concrete example, try wrap up a simple message queue system
in erlang and c++/java/..., compare the amout of work.  while erlang
has a good concurrency runtime, its immutable restrictions still helps
in making a good design.

basically, I believe "anything that can go wrong will go wrong".  one can
forget to lock but cannot modify immutables limited by language.

【 在 muser (负尽千重罪，练就不死心) 的大作中提到: 】
: 有什么具体事例支持这个说法吗？
--
FROM 180.173.114.*

【 在 muser (负尽千重罪，练就不死心) 的大作中提到: 】
: 墨菲定律，我觉得主要是心理上的感受。
: 现实中，爬火梯走钢丝的杂技演员多了。
: 编程也是。

but it is irresponsible to tell newbies to play acrobat.

: 刀梯上行走，不是求的刺激。而是知道，刀锋和皮肤接触后两者没有相对位移，就不会割伤。
: erlang我用过一年多。天之道，尺有所短寸有所长。所以，无论erlang 听上去如何完美，她也搞了个mutable 的 mnesia 数据库。

the point is not about never to use mutable state; it is that managing
mutable state is hard, so avoid it when unnecessary, and when necessary,
keep things manageable.  a database is a typical manageable global
mutable state; we all know how to manage it, and we assume we have only
one or a few of them.

: 我个人觉得，该做什么做就是了。需要锁就锁，不需要就不锁。所谓好坏都是放在某个上下文里才有意义的。

agreed.

and, well, in the context of webdev, and especially at the client side
as is the topic of this thread, the problem comes down to soft real-time
programming with deadline of 1/24 s, in a single thread using cooperative
multitasking in (explicit or implicit) continuation-passing style --- if
you lock, you are always in the GUI thread.  take your example, if you
lock a component to deny writes to its state, the logic may be:

- UI components discard user input if locked;
  of course, input is discarded, and if background computation accidentally
  took too long the UI just broke up.
- cancel background computation if any;
  cancellable promises are yet to mature, and side effects around
  cancelling require a lot of attention.
- buffer input and retry when unlocked;
  looks somewhat too complex to me, and, retry is not always desired.

in a 2-way binding, all these must be done before binding is updated, that
is, usually directly in the UI component.

but if using 1-way data flow, an UI component can blindly push out new
inputs, because we can easily plug-in a "locking" layer between the view and
controller/model.  in FRP this can be streams.  above problems are not
automatically solved, but there is no longer need to lock in every component
and every piece of logic code.

well, in 2-way binding the scheme can be emulated by taking a snapshot of
all required data before starting computations, but this already makes the
whole thing a 1-way flow.
--
FROM 183.195.251.*

【 在 muser (负尽千重罪，练就不死心) 的大作中提到: 】
: 哦，我说的“锁”，是锁定输入，类似 .disable=true;这种的。

disable DOM elements?  breaks MVC separation...

: 1/24 s，这说的是动画吗？

applies to all GUI programming; there is also a more strict deadline = 1/60s
--
FROM 183.195.251.*

我觉得，现在编程界文化革命是主流。 可是，break mvc 有什么关系吗？

不管黑猫白猫，抓住老鼠就是好猫。后来发明了老鼠夹子，有效。结果好了，只有夹住的才算是老鼠了....

个人管这叫：划地为牢，反客为主，本末倒置，削足适履....

我正在受这个文化影响的煎熬：有次改个小东西，一个参数连传了3层，就是为了政治正确性；还有一次，一个界面小改动，presenter, view, display...带资源文件，改了15个！
所以对所谓的分层、注入...优雅、正确...极痛恨。

【 在 XeCycle 的大作中提到: 】
:
: disable DOM elements?  breaks MVC separation...
:
: ...................
--
FROM 68.135.50.*