v0.0.3-alpha.1 dev

[JesseCoretta]

v0.0.3-alpha.1 dev notes

• Added preliminary FIFO (First-In-First-Out, a.k.a.: queue) support option, which complements the default LIFO (Last-In-Last-Out, a.k.a.: stack) behavior observed through use of the Stack.Pop method
  • For those unfamiliar with these concepts:
    • FIFO is akin to the line at the deli: first come, first serve. In technical terms, this means the first slice (#0) shall be removed when Stack.Pop is executed in this operating mode
    • LIFO is akin to a stack of plates in a box: last one in is at the top. In technical terms, this means the last slice (i.e.: length -1) shall be removed when Stack.Pop is executed in this operating mode
  • Users may execute Stack.SetFIFO(true) to invoke FIFO append/truncate behavior
  • Users should not change the scheme in effect once [de-]population has commenced during its lifespan
• Added Stack.Reveal method to recursively walk a Stack instance and disenvelop needlessly nested elements
  • Abstract example: And[And[And[1x Condition]]]
  • Stack-in-Condition scenarios will be included in this operation
  • For the moment, Not stacks are exempt from this control due to their inverse nature
• Added Stack.Defrag method to recursively correct contiguity "errors" (i.e.: gaps)
  • The method will scan the receiver instance and implode, or "collapse", the slices such that no nil instances exist between non-nil slices
  • When complete, the trailing nil sequence is truncated entirely (else the receiver length would have remained constant)
  • A genuine need for this method would likely be rare and quite unusual -- but not impossible
  • Stack-in-Condition scenarios will be included in this operation, as will Stack-in-Stack scenarios
• Decommissioned old chan-based event system in favor of basic *log.Logger functionality
  • Standard *log.Logger incarnations (e.g.: stderr, stdout) are available globally or per Condition/Stack
  • Custom *log.Logger instances may be provided by the user
  • Default logging state is to discard all log events using io.Discard, as is recommended
  • Included convenient LogLevel bit identifiers, allowing numerous verbosity-level permutations
  • Included ten (1) unnamed and reserved LogLevel bit identifiers for user customization
• Implemented Interface interface
  • Useful in situations where reduced type-assertion for Condition and Stack instances (or any qualifying aliased counterparts) would be appreciated by the end-user (this sentiment would apply in particular to extremely complex, nested structures).
  • The Interface interface only offers functionality that is inherently read-only, and only extends a subset of similar such methods that are common to both of the above root types in both name and signature
• Added/enhanced Len method support for Condition instances, the semantics of which are as follows:
  • If receiver is not initialized, or if no expression has been set, a length of zero (0) is returned
  • If receiver contains an expression that is a Stack (or alias of same) instance, its own Len() semantics apply and may return any integer (even zero (0))
  • A length of one (1) is returned as a fallback, representing the abstract length of a single Condition
• Added Addr method for both Condition and Stack type instances
  • This performs a crude internal call to fmt.Sprintf using the %p verb to print the memory address currently occupied by the underlying embedded instance
  • Mainly useful for unit tests, debugging or troubleshooting
  • Users who do not label their objects may find this mildly useful in some scenarios
• Added SetID method functionality to allow the (very) basic randomized generation of twenty-four (24) alphanumeric characters for convenient automatic naming of objects; this is triggered by the input of _random for an ID to set
  • math/rand is used, as this is not a security-sensitive feature
  • Similarly, _addr will automatically invoke the Addr method for the convenient naming of objects
• Added more traditional error handling support for Stack and Condition types, without sacrificing the fluent method signature design
  • Stack and Condition types now extends the Err() error method to allow the commonplace if err != nil-style checks for users who prefer that over the act of chaining fluent method calls that may obscure a particular problem's true source
  • Conversely, the SetErr(err error) <fluent return type> has been added to allow users to specify their own error conditions, when needed, or to unset an error instance already present within the receiver
• Misc. changes
  • Documentation improvements, typo corrections
  • Updated bullet-point documentation blocks to reflect the newer pkgsite syntax, thus avoiding the double-spaced lines between line-items that have plagued Gophers since the days of Godoc
• Misc. bug fixes
  • Corrected issue with Stack.Cap not returning the correct user-facing integer value
    • This did not impact the actual capacity -- only the expected number of slices were permitted for addition; no more and no less than that
    • The offset for the 'hidden' configuration slice was not reflected during interrogation procedures, thus a capacity of four (4) would return five (5) when Stack.Cap was executed
  • Corrected issue with Condition type conversion attempts failed due to incorrect control type defined
  • Corrected inconsistent pointer usage for Condition method signatures (Init is now the only *Condition signature bearer, as it should be)
  • Corrected issue where Condition.SetExpression was setting the native type instance of an assertion value, as opposed to the actual assertion value. For example:
    • User Bob submits type-aliased stackage.Stack instance -- let's say main.MyStack -- to a newly assembled stackage.Condition instance using its SetExpression method
    • The internal methods that evaluate the submitted assertion value will, at some point, check to see if the type instance is either a native stackage.Stack OR a type alias of same
    • In Bob's case, this check evaluted as true and the value was accepted
    • Unfortunately, the value that was actually written was the return value of an internal "alias->stack" converter; this should have been shadowed, and not used, as the process merely should look to see IF the assertion value is a stackage.Stack, but not actually use the converted value
    • The solution was simply to use the originally submitted value, as-is, once it passed the requisite checks
  • Corrected needlessly-padded Stack.Kind return value
    • Padding was originally applied to this value for string representation requests which contained one (1) or more Boolean WORD-based logical sequences (e.g.: value AND othervalue)
    • WORD operators should always have padding; SYMBOL operators may, or may not, have padding
    • Padding is now applied as expected, but is limited to operation within the String() methods, and no longer influences its component values directly outside of this scenario
    • Users and applications that were previously trimming the Stack.Kind() return value (e.g.: strings.TrimSpace(myStack.Kind())) may cease doing so at their leisure

[codecov-commenter]

Welcome to Codecov 🎉

Once merged to your default branch, Codecov will compare your coverage reports and display the results in this comment.

Thanks for integrating Codecov - We've got you covered ☂️