feat: remove super() checks in initializers

[sha-hil]

The super() in initializers in child classes are not always required. Hence, I believe this should be optional and should not be picked up by RC.

Example code where RC asks for super() but it is not required.

# frozen_string_literal: true

module Loyalty
  class V6LoyaltyRewardsCard
    class Base
      def state
        raise NotImplementedError, "Override in subclass"
      end

      def state_attributes
        raise NotImplementedError, "Override in subclass"
      end

      def activity_history
        {
          text: I18n.t("everyday_rewards.rewards_screen.activity_history_text"),
          url:  Settings.everyday_rewards.activity_history_url

        }
      end
    end

    class Empty < Base
      def state
        "LOYALTY_EMPTY"
      end

      def state_attributes
        {
          primary_text: I18n.t("everyday_rewards.rewards_screen.loyalty_empty_text")
        }
      end

      def activity_history
        raise NoMethodError, "Empty rewards card does not have access to activity_history"
      end
    end

    class Operating < Base
      def initialize(everyday_rewards_id:, balances:, cpl_discount:)
        @everyday_rewards_id = everyday_rewards_id
        @balances = balances
        @cpl_discount = cpl_discount
      end

      def state
        "LOYALTY_OPERATING"
      end

      def state_attributes
        {
          everyday_rewards_id: @everyday_rewards_id,
          cpl_discount: @cpl_discount,
          activity_history: activity_history,
          balances: @balances
        }
      end
    end

    class Error < Base
      def initialize(error_text:)
        @error_text = error_text
      end

      def state
        "LOYALTY_ERROR"
      end

      def state_attributes
        {
          primary_text: @error_text,
          error_image_url: "#{ApplicationConfig::EVERYDAY_REWARDS_IMAGE_BASE_URL}/#{Settings.everyday_rewards.rewards_error_image}",
          activity_history: activity_history
        }
      end
    end
  end
end

[LuyiPK]

LGTM, thanks Sha 👍

[invke]

Gonna challenge this, this is typically a syntax error on compiled languages, so I'm hesitant for us to remove a lint guard for it. See the thinking behind why this rule exists: rubocop/ruby-style-guide#809

rubocop/ruby-style-guide#809 (comment)

@silva96 In this particular example, it does nothing and perhaps the super call is not needed. The problem is that you don't know this is the case if the superclass is part of another library or maintained by someone else. The base class may add some initialization logic in the future that would not get run by your subclass.

It is worth pointing out that the Java language has required all constructors to call a superconstructor since the beginning for exactly this reason: not calling the superclass constructor breaks the guarantee that it will run when instances of that class or its subclasses are instantiated. Java code requires that the subclass invoke a superclass constructor directly, or else a call to the superclass's default (no-args) constructor will be inserted for you.

[sha-hil]

Ah yup I get it. It's better it remains for the situations like working with gems etc and a super() is needed. Cheers for that @invke !