Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an IObservable<int> ItemCount property to IReactiveList* #431

Closed
clairernovotny opened this issue Dec 10, 2013 · 8 comments
Closed

Add an IObservable<int> ItemCount property to IReactiveList* #431

clairernovotny opened this issue Dec 10, 2013 · 8 comments
Labels

Comments

@clairernovotny
Copy link
Member

Make it easy to subscribe to the list count.

@niik
Copy link
Member

niik commented Dec 11, 2013

@onovotny I realize it's not in the interface but ReactiveList has CountChanged which is an IObservable<int> so if anything it should probably be named that.

Seeing how easy it is to get an observable from the Count property itself using ObservableFromProperty I have to admit I'm conflicted on having a dedicated property tbh. But I'll defer that to @paulcbetts

@anaisbetts
Copy link
Member

I think that interfaces for collections are conceptually dumb, so I defer it to @haacked

@clairernovotny
Copy link
Member Author

Silly question, but isn't it better to never expose concrete details? So in my VM (or anywhere else), it'd only expose an interface.

Not only that, but if I wanted better encapsulation, like using the IReadOnlyReactiveList interfaces, those might still want to subscribe to all of the observables in the concrete type.

@clairernovotny
Copy link
Member Author

Since the IObservable's are already on the underlying collection, it should be as easy as adding them to the interfaces. I can do this and submit a PR if you want.

@haacked
Copy link
Contributor

haacked commented Dec 12, 2013

If this is already exposed on the underlying collection I see no harm in this. Send a PR. :)

@anaisbetts
Copy link
Member

👍

@anaisbetts
Copy link
Member

Silly question, but isn't it better to never expose concrete details?

For Classes That Do Stuff, I totally agree, but I look at ReactiveList the same way as I look as "Dictionary" or "string", it's more like a fundamental data structure than a class with a contract. While this is a bit of a stretch, I think that the interfaces generally just get in the way here.

The one useful semantic that the interfaces can describe wrt ReactiveList is, "Please don't change this list" (i.e. "read-only for you" semantics).

@clairernovotny
Copy link
Member Author

I guess I've always been in the camp of never exposing concrete collection types, including List<T>, Dictionary or anything else. I'd rather not have a caller store it as a List<T> in case I want to change the type later...like maybe use a linked list or a ReactiveList where it was just a List before.

@lock lock bot added the outdated label Jun 26, 2019
@lock lock bot locked and limited conversation to collaborators Jun 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants