Incorporate missing change proposals to RFC 00014 #595

georg-schwarz · 2024-06-21T05:58:36Z

I think we didn't integrate some change proposals we agreed on. This PR introduces those changes.

georg-schwarz · 2024-06-21T05:59:28Z

rfc/0014-attribute-based-valuetypes/README.md

- ];
+ property correlation oftype decimal;
+
+ constraint minusOneToPlusOneRange: MinusOneToPlusOneRange(value = correlation);


Not entirely sure if we really agreed on the syntax to call a constraint on a property

I don't think we did (and I don't think we have a constraint keyword somewhere that is not a constraint definition, right? I'd keep the suggestions in this PR more minimal with

constraints: [ MinusOneToPlusOneRange on correlation ]

I think that nicely aligns with our current syntax style (so doesn't introduce new concepts like constructor-like brackets and assignments). We will of course have to evolve on that (e.g. constraints over multiple attributes, AND/ORing constraints etc) but I'd do that in a later RFC.

How about the following?

constraint MinusOneToPlusOneRange on correlation;

I'd really like to get rid of the array syntax and more closely align with the "flat over nested" design principle.

You mean similar to the property syntax of just listing all the properties in that way? I am good with it, happy with your suggestion there.

Yes exactly. I feel like, currently, we have two different approaches to defining lists. And I'd like to introduce more consistency by also using the same flat syntax as for property

rhazn · 2024-06-24T10:04:00Z

rfc/0014-attribute-based-valuetypes/README.md

+1. more similar to traditional approaches and
+2. is needed anyway for multi-attribute value types.
+
+Thus, this RFC removes the `oftype` keyword in a value type definitions and proposes an attribute-based syntax that is extendable to a future multi-attribute syntax.


Suggested change

Thus, this RFC removes the `oftype` keyword in a value type definitions and proposes an attribute-based syntax that is extendable to a future multi-attribute syntax.

Thus, this RFC removes the reference to a parent value type in a value type definition and proposes an explicit attribute-based syntax instead that is extendable to a future multi-attribute syntax.

rhazn · 2024-06-24T10:09:23Z

rfc/0014-attribute-based-valuetypes/README.md

- ];
+ property correlation oftype decimal;
+
+ constraint minusOneToPlusOneRange: MinusOneToPlusOneRange(value = correlation);


I don't think we did (and I don't think we have a constraint keyword somewhere that is not a constraint definition, right? I'd keep the suggestions in this PR more minimal with

constraints: [ MinusOneToPlusOneRange on correlation ]

I think that nicely aligns with our current syntax style (so doesn't introduce new concepts like constructor-like brackets and assignments). We will of course have to evolve on that (e.g. constraints over multiple attributes, AND/ORing constraints etc) but I'd do that in a later RFC.

rhazn · 2024-06-24T10:10:36Z

rfc/0014-attribute-based-valuetypes/README.md

 ```

-While more verbose, it prepares the way for 
+The syntax is kept flat rather than using arrays.


Suggested change

The syntax is kept flat rather than using arrays.

The syntax is kept flat rather than using arrays in alignment with the [Jayvee Design Principles](https://jvalue.github.io/jayvee/docs/0.4.0/dev/design-principles#jayvee-manifesto).

This sentence does not make sense anymore if we apply @rhazn's suggestion above.

rhazn · 2024-06-24T10:12:42Z

rfc/0014-attribute-based-valuetypes/README.md

-While more verbose, it prepares the way for 
+The syntax is kept flat rather than using arrays.
+
+Despite referencing reusable constraints, the syntax also allows in-place constraint definition:


I would keep this out of the RFC to make it smaller. We should probably have in-place constraint definitions but imho can do so in a follow-up.

I wouldn't mind adding it here. It's not huge anyway.

Just for a view on the syntax, if we go with my suggestion, that would be:

constraints: [ value >= 1 and value <=1 on correlation ]

equivalent to

constraints: [ MinusOneToPlusOneRange on correlation ]

My issue with that was that reading the in-place constraint definition with the following "on" is kind of confusing... But honestly, seeing how it looks here I am kind of happy with it. So I'll revert what I said and say we should have in place constraints as well, yeah.

Why shouldn't we use

constraints: [ correlation >= 1 and correlation <=1 ]

?

And combined:

constraints: [ correlation >= 1 and correlation <=1, MinusOneToPlusOneRange on correlation ]

I don't see why we need to use on for in-place constraints as well

How would you model two different attributes in that case? The reason I put the on correlation at the end of the reference is to allow for more than one attribute, e.g. correlation and unit and you could have

constraints: [ value >= 1 and value <=1 on correlation, SomethingElse on unit ]

I'd semi-strongly feel about continuing to use value for inside the constraint and a clear reference to which attribute it is on to allow for future multi-attribute value types.

I use correlation instead of value.
This allows for example

constraints: [ correlation >= 1 and otherUnit <=1 ]

Ah, fair enough. I dislike that because it introduces different syntax for inline constraints vs. references and I like the ability to always just create a constraint reference by c&p the inline code. But that is something that reasonable people can disagree on :D.

I see your point @rhazn, and I see value in keeping the syntax consistent independently if defined in-line or as stand-alone element.

What do you think about changing the constraint definition syntax in a similar way to keep it consistent? Instead of the value keyword, constraint definitions would refer to the value type's properties they are based on:

constraint CorrelationCoefficient on decimal: value >= 1 and value <= 1; // "value" is the property name of builtin value types (so nothing changes for them) constraint PostiveCorrelationConstraint on CorrelationCoefficient: correlation > 0; // "correlation" is a property of the value type CorrelationCoefficient // Future, for multi-dimensional value types constraint Coordinate2DInLeftUpperQuadrantConstraint on Coordinate2D: x > 0 and y > 0;

An obvious downside is the circular dependency of value type and constraint that could be incentivized (or should be prevented by hinting to in-line constraints in such cases).

I rewrote this comment three times, not sure I can come to a strong opinion so in the end I would probably accept majority opinion, but:

I think that is unfortunate because it again introduces magic with the value name for builtin value types. It also still means it is weird to reuse constraints between inline definitions and general definitions. I would prefer if we keep value in general for one-dimensional value types.

I can not really think of a good way to model constrains on multi-dimensional value types that do not need to know the names of properties... For consistencies sake I would go with value.x. That does not resolve the issue of course, but it keeps the rule intact that value always refers to the underlying value of the value type.

joluj

I'm not really happy with the new syntax regarding the constraints. I like @rhazn's suggestion more, but I'm not really happy with that either.
But I think we will get better ideas when we use it a bit and when we think about AND, OR, XOR, ...

Since we need to go over the constraints later anyway, I'm fine with not finding an optimal solution now.

joluj · 2024-06-24T11:06:37Z

rfc/0014-attribute-based-valuetypes/README.md

+The current syntax, in which an underlying value type is referenced through 'oftype', it does not use instantiation/inheritance but rather composition.
+The purpose of using composition is that it is
+
+1. more similar to traditional approaches and


What is a traditional approach? Since you mentioned inheritance before, does it correlate to that?

joluj · 2024-06-24T11:08:21Z

rfc/0014-attribute-based-valuetypes/README.md

 ```

-While more verbose, it prepares the way for 
+The syntax is kept flat rather than using arrays.


This sentence does not make sense anymore if we apply @rhazn's suggestion above.

joluj · 2024-06-24T11:10:06Z

rfc/0014-attribute-based-valuetypes/README.md

-While more verbose, it prepares the way for 
+The syntax is kept flat rather than using arrays.
+
+Despite referencing reusable constraints, the syntax also allows in-place constraint definition:


I wouldn't mind adding it here. It's not huge anyway.

joluj · 2024-06-24T11:12:20Z

rfc/0014-attribute-based-valuetypes/README.md

+ property correlation oftype decimal;
+
+ constraint minusOneToPlusOneRange:
+  correlation >= 1 and correlation <=1;


Suggested change

correlation >= 1 and correlation <=1;

correlation >= -1 and correlation <= 1;

joluj · 2024-06-24T11:13:13Z

rfc/0014-attribute-based-valuetypes/README.md


 ## Alternatives

-Conceivably, we could use multiple inheritance for multi-attribute value types... just joking. 
+1. Keep the current syntax.
+2. Use arrays instead of the flat syntax.


Remember to remove this if we apply @rhazn's suggestion

Incorporate missing change proposals to RFC 00014

883988e

georg-schwarz commented Jun 21, 2024

View reviewed changes

georg-schwarz requested review from rhazn, joluj and dirkriehle June 21, 2024 05:59

rhazn approved these changes Jun 24, 2024

View reviewed changes

joluj reviewed Jun 24, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Incorporate missing change proposals to RFC 00014 #595

Incorporate missing change proposals to RFC 00014 #595

georg-schwarz commented Jun 21, 2024

georg-schwarz Jun 21, 2024

rhazn Jun 24, 2024

georg-schwarz Jun 28, 2024

rhazn Jun 28, 2024

georg-schwarz Jun 28, 2024

rhazn Jun 24, 2024

rhazn Jun 24, 2024

rhazn Jun 24, 2024

joluj Jun 24, 2024

rhazn Jun 24, 2024

joluj Jun 24, 2024

rhazn Jun 24, 2024

joluj Jun 24, 2024

rhazn Jun 24, 2024

joluj Jun 24, 2024

rhazn Jun 24, 2024

georg-schwarz Jun 28, 2024

rhazn Jun 28, 2024

joluj left a comment

joluj Jun 24, 2024

joluj Jun 24, 2024

joluj Jun 24, 2024

joluj Jun 24, 2024

joluj Jun 24, 2024

	Thus, this RFC removes the `oftype` keyword in a value type definitions and proposes an attribute-based syntax that is extendable to a future multi-attribute syntax.
	Thus, this RFC removes the reference to a parent value type in a value type definition and proposes an explicit attribute-based syntax instead that is extendable to a future multi-attribute syntax.

	The syntax is kept flat rather than using arrays.
	The syntax is kept flat rather than using arrays in alignment with the [Jayvee Design Principles](https://jvalue.github.io/jayvee/docs/0.4.0/dev/design-principles#jayvee-manifesto).

	correlation >= 1 and correlation <=1;
	correlation >= -1 and correlation <= 1;

Incorporate missing change proposals to RFC 00014 #595

Are you sure you want to change the base?

Incorporate missing change proposals to RFC 00014 #595

Conversation

georg-schwarz commented Jun 21, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joluj left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment