Convert confirm_form() in aggregator.admin.inc to the new form interface

picking this up

i know #1906474: [policy adopted] Stop documenting methods with "Overrides …" is still rtbc but i was being lazy and used inheritdocs, sue me:)
I have to think about the luck of aggregator_remove() too, lets see what bot says

random failure?
EntityTranslationUITest.php 40

#3: drupal-aggregator_confirm_form-1946324-3.patch queued for re-testing.

i should kill aggregator_remove()

Actually i won't cause then this will conflict with #1930274: Convert aggregator processors and parsers to plugins
I just added a todo and replaced inheritdocs:(
this should be committable now

I agree.

Committed to 8.x.

Excuse me.

It is completely beyond me how something like this:

-function aggregator_admin_remove_feed($form, $form_state, Feed $feed) {
-  return confirm_form($form,
-    t('Are you sure you want to remove all items from the feed %feed?', array('%feed' => $feed->label())),
-    'admin/config/services/aggregator',
-    t('This action cannot be undone.'),
-    t('Remove items'),
-    t('Cancel')
-  );

...can remotely turn into this:

+namespace Drupal\aggregator\Form;
+
+use Drupal\Core\Form\ConfirmFormBase;
+use Drupal\aggregator\Plugin\Core\Entity\Feed;
...
+class FeedItemsDelete extends ConfirmFormBase {
+
+  /**
+   * The feed the items being deleted belong to.
+   *
+   * @var \Drupal\aggregator\Plugin\Core\Entity\Feed
+   */
+  protected $feed;
+
+  /**
+   * Implements \Drupal\Core\Form\FormInterface::getFormID().
+   */
+  public function getFormID() {
+    return 'aggregator_feed_items_delete_form';
+  }
+
+  /**
+   * Implements \Drupal\Core\Form\ConfirmFormBase::getQuestion().
+   */
+  protected function getQuestion() {
+    return t('Are you sure you want to remove all items from the feed %feed?', array('%feed' => $this->feed->label()));
+  }
+
+  /**
+   * Implements \Drupal\Core\Form\ConfirmFormBase::getCancelPath().
+   */
+  protected function getCancelPath() {
+    return 'admin/config/services/aggregator';
+  }
+
+  /**
+   * Implements \Drupal\Core\Form\ConfirmFormBase::getConfirmText().
+   */
+  protected function getConfirmText() {
+    return t('Remove items');
+  }
+
+  /**
+   * Implements \Drupal\Core\Form\FormInterface::buildForm().
+   */
+  public function buildForm(array $form, array &$form_state, Feed $aggregator_feed = NULL) {
+    $this->feed = $aggregator_feed;
+    return parent::buildForm($form, $form_state);
+  }
+
+  /**
+   * Implements \Drupal\Core\Form\FormInterface::submitForm().
+   */
+  public function submitForm(array &$form, array &$form_state) {
+    // @todo Remove once http://drupal.org/node/1930274 is fixed.
+    aggregator_remove($this->feed);
+    $form_state['redirect'] = 'admin/config/services/aggregator';
+  }
+
+}

This is a 1,200% DX regression. How is that remotely acceptable?

Furthermore, why was this even converted to a "ConfirmFormBase" in the first place?

To my knowledge, aggregator categories and feeds are entities now, and the conversion of delete confirmation forms for entities via EntityFormControllers was and still is on the major todo list for D8.

That would be a larger part of #1913618: Convert EntityFormControllerInterface to extend FormInterface. But yes, see #1938600: Add a FormInterface replacement for confirm_form() for the details on the future of confirm_form().