Introduction of promise.return() and promise.throw() similar to generator.return() and generator.throw()

Igor Baklan io.baklan at
Thu Jan 12 22:36:48 UTC 2017

Yes, it's good note, that it can be "too public" and may be some one would
like to prevent external "intrusion" into it's "private state", but it can
be easily solved by the means of a wrappers, that wraps some private
``target`` and delegate to it only "safe calls", that will not
interrupt-it/cancel-it, it can look like
``privateSattePromise.preventAbnormalCompletion()`` - which returns some
wrapped promise with more "safe" behavior, then this promise can be shared
with "wider audience". But from the opposite side - if somebody make some
internal logic, and do not intend to return that internal objects
"outside", why he should complicate his life so much (and do not "trust
himself" if both methods - which produces some promise and consumes that
promise - are private in some place)? As an example of such kind of
wrappers I can offer you [``java(Collections#unmodifiableList)``](
It's conception is very simple - it takes some mutable list and wraps it by
some wrapper which prevents modification, as a result you'll obtain some
"semi-immutable" list, meaning that you will not be able modify it through
that wrapped instance, but still can do some changes over initial
collection, and that changes will be quite visible through the wrapper.

So from my point of view, it can be 2-wo approaches - always expose that
"external intrusion api", and the explicitly "hide" that api by the means
of some ``promise.giveMeSafeWrapper()``-like api. Or an other option, just
do not expose that api by default, and say that if you want to create that
"extra public" promise you should use some subclass of regular promise,
like ``extraPublicPromise = new Promice.ExtraPublic(executor)``, and the
ofcourse, it would be more explicit, which stuff is internal, and should be
wrapped before giving it somewhere outside, and knowing that all the rest
is "safe" in terms of "external intrusion".

But denying that capability at all, being to lazy for writing
``.giveMeSafeWrapper()``-like calls is also not very good choice (as for
me). (By the way, approach given in
[the-revealing-constructor-pattern#historical-origins]( doesn't looks
"so insane". Considering ``deferred = Q.defer();`` and ``p =
deferred.promise;``, I see that there are some public part and private part
of that object. And if they for example share most of api on both of them,
but private instance has "alittle bit more" available api for control, then
in would be not so bad idea. Again, not assuming that using private
instance for task completion should be "normal api", but as some sort of
"abnormal completion api" it can be quite useful).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list