Provide side-effect-free version of operators

[jeffbcross]

Right now each of the operator modules contain both the operator implementation AND the Observable-patching side effect logic. This prevents smart people like me from being able to safely import an operator without polluting the Observable prototype.

I think the right default behavior is to keep the side-effect-producing modules named as they already are, in the operators folder, and import from a "raw" module that exports the operator implementation.

I propose adding an implementation folder inside operators to contain actual implementations.

|- rxjs/
|-- operators/
|---- implementation/
|------ map.ts - actual implementation with no side effects
|---- map.ts // Just imports the raw `map` operator and patches it onto Observable

CC @robwormald @Blesh @IgorMinar

[benlesh]

I thought about this last night. In Babel, I'd much rather import the operator and use myObservable::operator() directly.

I'm generally for this change, but I think that implementation is a lot to type. impl is more palatable for me.

What if it were something like with or add or patch? Something that described what the import was doing:

import {Observable} from 'rxjs/Observable';
import 'rxjs/with/map';
import 'rxjs/with/filter';

and for direct operator imports:

import {Observable} from 'rxjs/Observable';
import {map} from 'rxjs/operator/map';
import {filter} from 'rxjs/operator/filter';

[jeffbcross]

@Blesh I'm in favor of flipping so that the side-effect free operator is in rxjs/operators/ and the patching-version is in rxjs/operators/${subfolder}. This is more forward-compatible with a future when we no longer need to rely on monkey patching. The subfolder needs a less verby name though.

[benlesh]

The subfolder needs a less verby name though.

But the act of importing anything under it is literally acting like a function with side-effects. It's executing code that has side-effects.

rxjs.addMap() vs rxjs/add/map so to speak.

[jeffbcross]

@Blesh I more meant that literally being a verb felt wrong to me, but a noun version of the verb would feel better. But I don't really have a standard or convention to point to to justify my feelings, and I haven't thought of a better name (other than monkey-patchers)

[IgorMinar]

I'm fine optimizing for the future and moving the modules with side-effects into a separate directory.

so rather than impl we would have patch or similar directory that we would use until function bind is a thing. how about that?

[IgorMinar]

add as suggested by @Blesh is even better than patch

[jeffbcross]

@IgorMinar no no no, go back to what you suggested with patch. Patch is beautiful because it's a verb AND a noun.

[jeffbcross]

I realize @Blesh proposed patch in his original comment, and I've now come around to liking patch.

[IgorMinar]

rxjs/add/map reads as add map to rxjs.

rxjs/patch/map reads as patch map to rxjs.

I guess both are fine. "add" is one char shorter.

I'm fine with either. Let's have Ben decide.
On Tue, Dec 1, 2015 at 5:32 PM Jeff Cross notifications@github.com wrote:

I realize @Blesh https://github.com/blesh proposed patch in his
original comment, and I've now come around to liking patch.

—
Reply to this email directly or view it on GitHub
#860 (comment).

[benlesh]

LOL. Anyone else have an opinion? @kwonoj? @trxcllnt? Haha

[kwonoj]

One of my biggest weakness is always about naming class, variable, module, etcs whatever, especially in English 😓 . Personally bit prefer patch though it's somewhat longer than add. (or mutate? update? not sure.)

[benlesh]

Okay, my pick is add:

Reasons:

1. 2 keys
2. 3 characters

... also I'm hope to make a BurgerObservable at some point with operators for lettuce, tomato, pickle, etc. Using "patch" will make that less fun.