flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <olegsivo...@gmail.com>
Subject Re: Actionscript workers and async locking?
Date Mon, 26 Mar 2012 09:46:26 GMT
Cosma Colanicchia, what I'm trying to say is that the perceived simplicity
of another approach is not such. The entire process is more complex, and
you cannot reduce it's complexity beyond certain level. Granted the
approach you illustrated, certain essential parts will be lost. This is the
situation called "leaky abstractions", i.e. when an attempt to abstract
further (an attempt to reduce complexity in this case) will produce more
problems then it solves.
What you are trying to show as simple doesn't have necessary parts any
non-trivial program will require. When these parts are added, the solution
you suggest will not be any less complex then the existing one, more so, it
will probably more complex and clumsy because it is not designed to handle
the real life situations.

Well, you shouldn't return anything from an event handler, that's the
limitation of the system, however it doesn't affect the type check, because
you don't expect handlers to return anything anyway (you are never in a
situation that would allow you to expect anything to be returned from a
handler). Same thing about if blocks or loop blocks - they don't return
anything in AS3. This is unfortunate, but this is a limitation of the
system. Trying to lift this limitation would result in a more complex
implementation, possibly, the results aren't worth the effort.

There is yet another concern. Older languages, such as C++ illustrated that
when you have an API that duplicates another API, the language overall
becomes more complex and the programmers will become superstitious about
one kind of the API. I don't see any benefit of your approach compared to
what already exists. Having two different approaches is worse then having
only one in this particular case.

In any case, I think I said this already. If and when there will be threads
/ workers / processes / w/e it'll be called, what you suggest will
certainly get used a lot, because it's something that, on the surface of
it, is "asking to be done". So that will be another case of newbies coming
to forums / irc for help and being educated not to do it in the way you
suggest because of non-obvious complications that will certainly happen.
It's the same case as it is today with anonymous functions, use of 'with'
construct etc - something that on the surface of it should make the work
easier, but in reality complicates it that much, you would rather avoid it
as a rule.



This suggest reduced quality in exchange for simpler implementation -
something that I personally wouldn't accept, but I'm not arguing this
should be the case for everyone.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message