Igor Baklan (2017-01-12T22:36:48.000Z)
io.baklan at gmail.com (2017-01-12T22:50:46.504Z)
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)``]( https://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#unmodifiableList(java.util.List)). 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 wrapped one. 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 then 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 that was described in [the-revealing-constructor-pattern#historical-origins]( https://blog.domenic.me/the-revealing-constructor-pattern/) 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 would 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, assuming that using private instance for task completion should NOT be "normal api", but as some sort of "abnormal completion api" it can be quite useful).
io.baklan at gmail.com (2017-01-12T22:47:49.966Z)
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)``]( https://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#unmodifiableList(java.util.List)). 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 wrapped one. 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 then 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 that was described in [the-revealing-constructor-pattern#historical-origins]( https://blog.domenic.me/the-revealing-constructor-pattern/) 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 would 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).
io.baklan at gmail.com (2017-01-12T22:43:56.523Z)
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)``]( https://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#unmodifiableList(java.util.List)). 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 wrapped one. 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 then 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 that was described in [the-revealing-constructor-pattern#historical-origins]( https://blog.domenic.me/the-revealing-constructor-pattern/) 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).
io.baklan at gmail.com (2017-01-12T22:42:10.575Z)
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)``]( https://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#unmodifiableList(java.util.List)). 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 wrapped one. 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 then 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]( https://blog.domenic.me/the-revealing-constructor-pattern/) 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).
io.baklan at gmail.com (2017-01-12T22:41:03.029Z)
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)``]( https://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#unmodifiableList(java.util.List)). 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 wrapped one. 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]( https://blog.domenic.me/the-revealing-constructor-pattern/) 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).