[PUP-6924] Fix issues with bad separation of concern between Array, Hash and Collection types Created: 2016/11/16  Updated: 2017/02/02  Resolved: 2016/11/28

Status: Closed
Project: Puppet
Component/s: None
Affects Version/s: PUP 4.8.0
Fix Version/s: PUP 4.9.0

Type: Bug Priority: Normal
Reporter: Thomas Hallgren Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: maintenance
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Team: Puppet Developer Experience
Story Points: 1
Sprint: PDS 2016-11-16, PDS 2016-11-30
Release Notes: Not Needed
Release Notes Summary: no user visible change
QA Contact: Eric Thompson
QA Risk Assessment: No Action
QA Risk Assessment Reason: internals; refactoring


This ticket is about Puppet Type internals and what's proposed here does not affect how the types are declared or represented.

In the current implementation, the Collection type has both a size_type and an element_type attribute. This, despite the fact that only the size_type is present in the specification. The element_type cannot be declared as a parameter and it is also never included in the string representation of the type. The only reason for it being present in the Collection is to provide some common functionality shared between the Array element_type and the Hash value_type.

The current design has several negative consequences.

  1. The code is unclean. It's hard to understand why and when the element_type is significant in the Collection type logic.
  2. It makes the Collection type carry an unnecessary attribute.
  3. It imposes the name element_type on the Hash type although the name there really should be value_type (to correspond with key_type).
  4. It has a negative impact on serialization of the Collection type since special logic must be added to understand that the element_type shouldn't be included. This must be fixed (hence the bug status rather than improvement in this ticket).

Comment by Henrik Lindberg [ 2016/11/17 ]

merged at c7450bb

Generated at Mon Jul 13 20:38:25 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.