Command Lists

[Phrogz]

Command List support. In short:

# Do not parse response (for speed)
@mpd.command_list do
  add song
  volume 50
  shuffle
end

# Array of values from each response line
ids = @mpd.command_list(:values) do
  addid song1
  addid song2
end
#=> [113,114]

# Single hash (with possible array values)
ids = @mpd.command_list(:hash) do
  addid song3
  addid song4
end
#=> { id:[115,116] }

# Array of hashes (split on first-value heuristic)
ids = @mpd.command_list(:hashes) do
  addid song5
  addid song6
end
#=> [ {id:117}, {id:118} ]

# Array of Songs (split on first-value heuristic)
ids = @mpd.command_list(:songs) do
  where genre:'electronic'
  where genre:'trance'
end
#=> [ <MPD::Song>, <MPD::Song>, ... ]

# Array of Playlists (split on first-value heuristic)
ids = @mpd.command_list(:playlists) do
  clear
  where({genre:'electronic'},{add:true})
  save 'new-playlist'
  playlists
end
#=> [ <MPD::Playlist>, <MPD::Playlist>, ... ]

[Phrogz]

Includes support for new playlist commands in the command list. These methods accept either a playlist name or a playlist as the identifier.

[Phrogz]

Playlists can be passed as params in command lists methods where a playlist name is required.

[Phrogz]

@archseer Any thoughts on this?

[Phrogz]

@archseer ping?

[archseer]

Sorry, I've been traveling and it's a big feature to look over; I'll
allocate time on Monday to review this :)

On Saturday, 27 February 2016, Gavin Kistner notifications@github.com
wrote:

@archseer https://github.com/archSeer ping?

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

[archseer]

Hmm, I'm not too thrilled about having another implementation of the playlists just for the command list. Do you think it would be possible to reuse the original MPD::Playlist objects? It won't be possible to fetch it and then reuse it in subsequent commands in the list, but that's not possible with these plain method calls either

[Phrogz]

All the playlist methods currently use @mpd.send_command. MPD#send_command includes handle_server_response and parse_response which we can't have called immediately with a command list. I can get around this for all the other MPD methods because they just call send_command (without an explicit receiver) and I provide my own send_command implementation for CommandList::Commands.

The only way that I can think to re-use the playlist objects would be to use an instance variable set as a flag when the command list was started and mutate the way send_command works everywhere under such circumstances. (I don't think I need to worry about tracking this state per thread, since multiple threads trying to use the same MPD instance would cause problems with the socket communication.)

I'd also have to modify MPD::Playlist#songs to handle the case when no result is returned from send_command, but I've already done something similar in a few other places as part of this patch.

Would you prefer that approach? Having MPD#send_command modify its behavior based on an instance variable tracking whether we're in a command list or not? Does this feel better to you?

[Phrogz]

Short summary of all the above: I will create an alternate pull request for consideration that modifies MPD#send_command to be aware of command-lists, to not grab the mutex and not handle any response in that mode, and to record the expected return type. This will allow playlists to be used in command lists directly, will even allow the same MPD instance to be used inside the command list, and will allow for the return value of command_list to be robust and correct (when desired), without the programmer specifying how to parse the response.