LeadSimple / boring-service

A simple implementation of the service-object pattern
MIT License
0 stars 1 forks source link

Support typing arrays #4

Open Andy9822 opened 2 months ago

Andy9822 commented 2 months ago

As a follow-up of #2, I noticed that this library lacks support of typed arrays out of the box today. Yes, we can achieve it with a Proc but it feels like a very common case so ideally should be built-in.

The main problem is HOW we are going to support it. More specifically, the syntax / API for it. Let's grab the example from #2 where we added multi-types for parameters

class CalculatorService < BoringService
  parameter :num_1, [Float, Integer]
  parameter :num_2, [Float, Integer]

  def call
    puts "Sum of #{num_1} and #{num_2} is equal to #{num1 + num_2}"     
  end
end

The [Float, Integer] means that the type of the parameter is "any of the types inside of that array". What if we wanted to have a parameter that is an array of numbers? I'd like to support it in a very "high-level" way where it'd be basically a sugar syntax for a more boring check.

class CalculatorService < BoringService
  parameter :numbers, ????

  def call
    puts "Sum of numbers is equal to #{numbers.sum}"     
  end
end

Options:

  parameter :numbers, [Float, Integer], array: true # This replicates the Rails migrations implementation for creating an array column
  parameter :numbers, [[Float], [Integer]] # I hate the syntax, and it only supports arrays of floats or arrays of integers, not both in the same array
  parameter :numbers, Float, Integer # I came up with this while taking with Rafa. When there are many types it becomes a mess
Andy9822 commented 2 months ago

I'd personally go with my first option. I believe it's the one that feels the most natural to any engineer interested in using this library.

parameter :numbers, [Float, Integer], array: true

I'd be okay if we named it is_array: true or something similar, just wanted to focus on the "array option" part. WDYT @jeffdill2 @rafaeelaudibert ?