Abstract Enumerator further

[Burgestrand]

Turns out Playlists, Playlist Containers and… Searches not only allow you to retrieve a specific object by its’ index, but also some status information on it and even allow you to modify fields.

Say, for Playlists, we have sp_track *sp_playlist_track_message (sp_playlist *playlist, int index). Thing is, we also have:

int sp_playlist_track_create_time (sp_playlist *playlist, int index);
sp_user * sp_playlist_track_creator (sp_playlist *playlist, int index);
bool sp_playlist_track_seen (sp_playlist *playlist, int index);
sp_error sp_playlist_track_set_seen (sp_playlist *playlist, int index, bool seen);
const char * sp_playlist_track_message (sp_playlist *playlist, int index);

It is clear that Hallon need to support these (or similar) API calls:

playlist.track[0].name # called on track
playlist.track[0].artist   # called on track
playlist.track[0].creator # called through playlist_track_creator
playlist.track[0].seen = true # called through playlist
playlist.track[0].message # called through playlist

I am thinking some kind of proxy object where you explicitly define your extra methods, and any other methods fall through to the underlying object at that position. Oh well, that’s for another day.

[Burgestrand]

Created a proof-of-concept: https://gist.github.com/1243487

[Burgestrand]

Another option is to subclass Track, (making a PlaylistTrack or whatever) that holds a back-reference to the playlist somehow, and as such allow look-ups on these additional methods; like creator, seen= and so on. It’d have the drawback of requiring you to keep a reference to the Playlist, however.

There’s also the option of doing it like this:

playlist.track_seen[0] = true
playlist.track_creator[0]
playlist.track_message[0]

I think I prefer one of the two choices above; but this last one would map better to the Spotify API.

[Burgestrand]

Now that I think of it, the PlaylistTrack (would probably be Playlist::Track) option is way more clean.

1. You keep a reference to the playlist; you need to do that anyway.
2. The resulting track is a Track, with additional behaviour (+1 subclassing).
3. It would be easier to document, and far easier to read and understand the code.

It’s settled. Waiting until the implementation is done to close this issue.

[Burgestrand]

Alright, added an implementation of it in Playlist::Track with 0f284be. Closing this issue.