[FEATURE ember-metal-stream]

[rwjblue]

Expose the base internal stream implementation as Ember.Stream.

[stefanpenner]

@Private, or _Stream for now

[jmurphyau]

Are Stream's ever going to be exposed?

I'm just wondering if the way I've implemented a 'lookup' helper should/will change. Since its supposed to return a stream that changes independent of either the 'obj' (params[0]) or 'key' (params[1]) streams I couldn't see how it could I could implement this as a regular bound helper and/or without Streams

export function lookupHelper(params, hash, options, env) {
    var obj = params[0];
    var key = params[1];

    if (isStream(obj) && isStream(key)) {
        var accessKey = "lookup:$%@-$%@".fmt(Ember.guidFor(obj),Ember.guidFor(key));

        //can't contain '.' characters otherwise it will call child properties
        accessKey = accessKey.replace(/\./,'-');

        var stream = this.getStream(accessKey);

        //make sure it's not setup more than once
        if (!stream._isLookup) {

            stream._objStream = obj;
            stream._keyStream = key;

            stream._setLookupSource = function() {
                // sets the source object of this stream. any changes to the value 
                // of the source stream will automatically trigger this stream to refresh

                var sourceStream,
                        keyVal = read(this._keyStream);

                if (!Ember.isNone(keyVal)) {
                    sourceStream = this._objStream.get(keyVal)
                } else {
                    sourceStream = null;
                }

                this.setSource(sourceStream);
            };

            // when the value for 'key' changes, call 'stream._setLookupSource'
            // which will set the 'source' to a new stream object. 
            subscribe(stream._keyStream, stream._setLookupSource, stream);

            stream._setLookupSource(); 

            stream._isLookup = true;   
        }

        return stream;
    }
}

[rwjblue]

Rebased, and updated to ensure everything exposed is properly marked as private.

[mixonic]

@mmun this is for you to merge imo. It is behind a FF and private, low risk.

@jmurphyau we definitely want to expose them- but we're also wary of formalizing an API before it settles. If you need to reach for streams in your application code, it probably points to a missing API at a higher level.

[mmun]

@jmurphyau This seems like a good ember add-on: ember-cli-lookup-helper. It should probably know how to deal with streams/non-streams for both object and key (so 4 combinations). Our current implementation only deals with static keys.

EDIT: Actually may we can just add this to KeyStream. There's basically no cost to it.

[rwjblue]

Rebased.

[mmun]

@rwjblue I don't see the point of exposing them privately. It's not much better then Ember.__loader.require. Let's make em public!

[rwjblue]

@mmun - So make the util methods @public, but leave Ember._Stream as private? Or make 'em all public?

[mmun]

@rwjblue All public, I think!

I think we should jam everything into Ember.stream.*.

Ember.stream.read
Ember.stream.Stream
Ember.stream.KeyStream
Ember.stream.conditional
...

[rwjblue]

@mmun - Updated.

[mmun]

Excellenté

[ebryn]

Ember.stream.Stream seems weird

[mmun]

Agreed. This is my "fault". I wanted to put everything in Ember.stream._ because I expect it will become import _ from "ember-streams".