Skip to content

function: Refactor name validation to utilize new internal/fwfunction parameter validation interfaces #967

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
austinvalle opened this issue Mar 20, 2024 · 1 comment · Fixed by #991
Closed

function: Refactor name validation to utilize new internal/fwfunction parameter validation interfaces #967

austinvalle opened this issue Mar 20, 2024 · 1 comment · Fixed by #991
Assignees
@bflad
Labels
tech-debt Issues tracking technical debt that we're carrying.
Milestone
v1.9.0

Comments

@austinvalle
Copy link
Member

Module version

v1.6.0

Proposal

Following #964 and the v1.7.0 release, we should refactor the parameter Name required validation to utilize the internal/fwfunction interfaces for validating parameters.

Perhaps can be added alongside #965
@austinvalle austinvalle added the tech-debt Issues tracking technical debt that we're carrying. label Mar 20, 2024
@austinvalle austinvalle mentioned this issue Mar 20, 2024
Merged
@bflad bflad self-assigned this Apr 23, 2024
@bflad bflad added this to the v1.9.0 milestone Apr 23, 2024
bflad added a commit that referenced this issue Apr 23, 2024
@bflad
function: Missing underlying type validation and refactor parameter n…
5c279c2 
…ame validation

Reference: #965
Reference: #967

The framework will now raise implementation errors if a function parameter or return definition is missing underlying type information (e.g. collection element type or object attribute type).
@bflad bflad mentioned this issue Apr 23, 2024
Merged
bflad added a commit that referenced this issue Apr 24, 2024
@bflad
function: Missing underlying type validation and refactor parameter n…
a150eef 
…ame validation (#991)

Reference: #965
Reference: #967

The framework will now raise implementation errors if a function parameter or return definition is missing underlying type information (e.g. collection element type or object attribute type). Only framework types are considered in the initial implementation.
@github-actions GitHub Actions
Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 25, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@bflad bflad

Labels
tech-debt Issues tracking technical debt that we're carrying.
Projects
None yet
Milestone
v1.9.0
2 participants
@bflad @austinvalle