GitLab

Signed-off-by: Mark Stenglein <mstengle@gmu.edu>

Signed-off-by: Mark Stenglein <mstengle@gmu.edu>

- Going to need to work on getting the ability to add with a string
  or a string[]. Might just make it only work with Array and go back
  to clean up the API later.

details

- needed to change the other classes to support the AltRep and other
  classes to come.

- Also added test cases to cover the new class

- and who doesn't love nyan?

- Onward to greater page numbers in the RFC!

- Missed some pesky parentheses

- Committing to keep changes small and in case @yoda is also working
  on it right now.

- To help out folks like @zosman who might want to contribute,
  I've gone ahead and pulled out the definitions for tested
  components and put their ABNF definitions along with its page
  number from the RFC document.

- I moved some of the methods out of util and into Parameter for
  the moment so that I can figure out what the problem is that is
  causing the Parameter to not construct properly.

  - I added a fake stub method in ContentLine which just returns
  true all the time for now just so that the test cases will still
  compile properly.

- At this point all of the tests need to be written so that I can
  isolate the issue and hopefully fix it. Getting close to being
  able to actually implement iCal features! 🎉

- The vast majority of these tests still need to be written.
  - But hey, they're there! 😛

- The changes to the API I made required that I fix this test file.

- This file still fails, I need to finish the lower level Parameter
  test file before I can be sure where the issue actually lies.

  - Ideally that will be the contents of the next few commits.

- I put a lot more work here into the API
  - Now uses a bit better organization where the base param class
  is only going to enforce string contents. Implementations of
  specific kinds of parameters need to add their own datatypes and
  be sure to update the string value whenever the set method is
  called for their class. The parent class will take care of ensuring
  that anything written to this value (which is used directly in the
  generate step) is valid. Any higher level validations can then be
  taken care of by the higher level implementations, which shouldn't
  need to worry about the lower level validations.

- All of these new things really need test cases written for them
so that we can be sure that it works. It's going to get hairy looking
for bugs on the higher level classes if this doesn't have a solid test
foundation.

- just need to read each section and implement