IQbservable Rename to IAnswerable, IConversable, I? RRS feed

  • General discussion

  • I've been so busy with other projects that I haven't had time to keep playing with (and trying to break) Rx. With the recent video featuring Bart De Smet, I felt that IQbservable's need for a new name was dire indeed. 

    So here are my ideas, least favorite to most favorite:

    • IAnswerable
    • IConversable
    • IAsyncQueryable

    Just some ideas, IAnswerable implies the source of the data is capable of being answered, which is backwards sounding. IConversable implies the source of the data can be conversed with, but that seems to imply IQueryable + IQbservable, that is, two way. 

    I'm very partial to IAsyncQueryable. The public interface for IQbservable is so close to IQueryable, that for 90% of the name to be the same as IObservable belies the fact that the interface is 90% the same as IQueryable (the effect is very different!)

    Are there any other ideas floating around the Rx team's heads? Are you guys getting used to saying "Eye-Cubeservable" yet?

    All posted code is licensed under the Creative Commons CC-BY license unless stated otherwise.
    Tuesday, May 18, 2010 10:12 PM

All replies

  • I like IAsyncQueryable... much easer to say than "Eye-Cubeservable" :-P
    Wednesday, May 19, 2010 12:58 AM
  • We really do pronounce it in its long IQueryableObservable form. While we do value names, we're keen on getting the semantics right first :-). We're trying to apply in reverse (a good thing!). This said, every Rx-related discussion topic is welcome on the forum of course, including naming debates.
    using (Microsoft.Sql.Cloud.DataProgrammability.Rx) { Signature.Emit("Bart De Smet"); }
    Wednesday, May 19, 2010 1:55 AM
  • Thanks for the reply Bart! I'm always happy to see you and Erik post here, and I think you did a good job explaining IQueryable, for the majority of people who've never touched System.Linq.Expressions, LINQ to SQL and others have been a black box. (And that stuff is really cool, I don't know why it's not more talked about!)

    I digress though. As for the name of IQbservable, it's seeming, beginning to seem like Rx may either be finalized and released with a permissive license or included in the BCL in a future release* and while it's still in incubation, people are going to be writing software against it and it just seems, I don't know, difficult to read and it looks so similar to IObservable when I'm writing code. At least with QWERTY I don't need to worry about a typo, but when writing interfaces or methods that touch on either or both, it can quickly become difficult to tell which is which. I'm glad you're open to discussion on the matter and hopefully this post will provoke someone to come up with a particularly good name for what IQbservable should be. For the time being, when testing Rx I'll use a "using" declaration to rename the type to something a little more distinguishable.

    * - I know that you guys probably can't make any comment on this.



    All posted code is licensed under the Creative Commons CC-BY license unless stated otherwise.
    Wednesday, May 19, 2010 2:08 AM
  • We're still figuring out where and how to ship Rx to the masses, beyond our first release that will be available in the Windows Mobile 7 ROM (that one doesn't contain IQbservable as it was snapped prior to that point and various required APIs may not be available on the device anyway). One advantage of not being tied to any big release at this point is our ability to move fast and explore various segways, so the word "finalized" is quite an understatement for "Rx in the large" (though the core is starting to experience far less churn than it did before).

    Concerning the naming debate; feel free to keep it going :-). As you all know, the Rx team is keeping a close eye on the forums.

    using (Microsoft.Sql.Cloud.DataProgrammability.Rx) { Signature.Emit("Bart De Smet"); }
    Wednesday, May 19, 2010 7:29 AM
  • Hi Bart,

    The video was great, thanks, but I agree with Aaron that the name needs improvement :)

    How about IOQueryable?  (The I/O has double meaning ;)

    - Dave
    Wednesday, May 19, 2010 1:13 PM
  • My prefs:


    1. IReactiveQuery
    2. IReactiveQueryable
    3. IOQueryable

    --Scott W.
    Thursday, May 20, 2010 2:04 AM
  • If they are going to change the name to anything, it should be to IQueryableObservable. That's exactly what it is! It would be confusing to introduce yet another name into the picture.

    It is a real shame IQueryable isn't called IQnumerable or IQueryableEnumerable.

    Thursday, May 20, 2010 7:48 AM
  • Hi,

    James makes a good point.  I bet the FCL team would just use the expanded form.  Given that in VS 2010 you can just enter IQO+Tab it's not such a problem that it's long.  Furthermore, it's quite rare in the world of LINQ to even see IQueryable at all - it's usually hidden away by a var or within another query; I suspect IQueryableObservable will prove similar in practice.

    Edit: Here's another observation: IQueryableObservable is shorter than IConnectableObservable ;)

    - Dave
    Thursday, May 20, 2010 11:54 AM
  • "Here's another observation: IQueryableObservable is shorter than IConnectableObservable ;)"

    Haha... you're right!

    And I suppose we might need an IGroupedQueryableObservable ;)

    *Edit: although apparently not;

    public static IQbservable<IGroupedObservable<TKey, TSource>> GroupBy<TSource, TKey>(this IQbservable<TSource> source, Expression<Func<TSource, TKey>> keySelector)

    Thursday, May 20, 2010 4:26 PM
  • IObservableQuery is a little shorter, and keeps the IO prefix.

    IQueryableObservable seems like it's a subtype of IObservable in the same way an IConnectableObservable is a subtype of IObservable. But to call IQueryable a subtype of IEnumerable is tragically wrong, given the wholly different approach and profoundly more powerful mechanism of operation. IQueryable lets you write PLINQ, LINQ to SQL, LINQ to Entity Framework, whatever, IEnumerable doesn't give you something you can tweak, you take it or leave it.

    So I think Observable should be the adjective and Query/Queryable the noun: IObservableQuery or IObservableQueryable.

    That is if you're going to use the full name.

    All posted code is licensed under the Creative Commons CC-BY license unless stated otherwise.
    Thursday, May 20, 2010 10:46 PM
  • Interfaces denote an "is a" or "supports" relationship. Hence IQueryable is relately okay to be a derived from IEnumerable (well, concerning this particular discussion topic that is) since every such query can be enumerated over to provide its results. Things would be nicer if it reflected its enumerability in the type name. The real only difference lies in the extension methods provided on both interfaces; they only differ in signature following the homo-iconicity discussion. From that perspective, names that are close are... (feel free to fill in the dots).
    using (Microsoft.Sql.Cloud.DataProgrammability.Rx) { Signature.Emit("Bart De Smet"); }
    Friday, May 21, 2010 3:16 AM
  • I prefer IQueryableObservable over IQbservable . It's much easier to read, say, and more clearly says what it is. As much as I appreciate brevity, I appreciate a clarity more.
    Monday, May 24, 2010 11:20 AM
  • I think IQueryableObservable clearly states the purpose of the interface and any class that implements it.  However, it's a handful (mouthful).


    Why not try IQueryObservable, or IQObservable.  The focus here is the observability of the interface, right?

    Saturday, May 29, 2010 10:46 AM
  • I completely agree that IObservableQuery is the best name. What is this really anyway? A query that is observable.
    Thursday, July 8, 2010 9:30 PM
  • I wonder how IQbservable made it through the .Net Framework naming review process. If you watch the very first Rx presentations of Chan9 you will notice that in an early stage a couple of combinators had diffrent names (IMO better ones if you have a background in functional programming) and were changed by the evil "we have to find names and to make it look more Microsoftish ... and maybe ensure this way that the ex-VBlers won't be scared by functional concepts" paradigm. Maybe behind it is the unofficial rule list which contains things like: "APIs must not contain words Map&Reduce because that would look as if we copied Google". :0)

    Or maybe the responsible reviewer simply overlooked the Q and thought it would be IObservable :) In that way it was probably a good trick of Bart and the others to bring a stylish name into production.

    Although I think that IQbservable does not fit in the overall .Net and Rx naming scheme I am not a fan of drastic API changes after RTM releases .. thus I would vote for sticking with the geeky-name. A least it makes the Rx API less dull. :-).

    Friday, July 9, 2010 9:09 AM
  • First off, Bart, Thank you for yet another excellent Channel 9 video. You have a great way of explaining difficult concepts including both the IQObservable and LINQ to Everything videos. Keep them coming.

    As for the IQObservable, I have to wonder if including "Query" here is somewhat limiting. With the inclusion of time and action based combinators (Do, Run, BufferWithX, Throttle etc), it appears that we have moved beyond just the ability to query, but offer full programming expressions. Since the interface in essence combines the Observable with the ability to track the expression tree, I wonder if something like IExpressableObservable would make more semantic sense than IQueryableObservable.

    I realize we may be too late in the game for such a change, but wanted to throw it out there. We really aren't just talking about query at this point. - "LINQ In Action", The book is now available. Don't wait for the movie
    Tuesday, August 10, 2010 1:03 PM
  • Hi Jim,

    Interesting point of view, but I think query implies without side-effects, whereas expression does not; i.e., Rx hasn't left the realm of queryness yet.  :)

    The semantic purpose of a query regardless of what constructs it uses is to ask a question of the data source.  In the case of Rx, it's an observable data source; e.g., what values are grouped at each X time interval? (BufferWithTime), or what was the last value after the data source has been silent for X time interval? (Throttle).

    However, an expression is more general-purpose and may be used to do something.  An expression doesn't have to just ask a question of a data source, it can also mutate a data source.  Expressions in LINQ can now do things as well as ask things, although notice that the C# compiler can't transform all possible lambda expressions into LINQ expressions as of .NET 4.0, yet IQbservable still works fine without it.

    Of course, in C# we can put side-effects anywhere, including in LINQ queries.  But that's typically not the best approach to forming a query when it can be avoided.

    There is actually a combinator that is meant to explicitly express side-effects in a query: Do.  But all other combinators in Rx seem to me to be semantically equivalent to the parts of a query, not an expression.  Rx doesn't provide combinators for all possible expressions that you could use to cause side-effects in imperative code; e.g., assignment, or over data that isn't just a lazily-computed sequence of values; e.g., unary operatorsremove, clear, etc.

    As for Run and Subscribe, they aren't combinators.  In terms of duality with IEnumerable, they are like the body of the foreach.  Their purpose is to use the results of the query, often to cause side-effects.  They are used to define the continuation after the query returns; i.e., what the program does with the answer (values) to the posed question (query).

    - Dave
    Tuesday, August 10, 2010 3:28 PM