Skip to content
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.

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

Support read-only properties somehow #631

Closed
Zruty0 opened this issue Aug 2, 2018 · 2 comments · Fixed by #640
Closed

Support read-only properties somehow #631

Zruty0 opened this issue Aug 2, 2018 · 2 comments · Fixed by #640
Labels
API Issues pertaining the friendly API

Comments

@Zruty0
Copy link
Contributor

Zruty0 commented Aug 2, 2018

As mentioned in #254 , now that we are supporting both fields and properties for the purposes of schema comprehension, it is possible to create properties that act like 'calculated fields':

        public class MyDataRow
        {
            private DateTime _dateTime;

            public float Day { get { return _dateTime.Day; } }
            public float DayOfWeek { get { return (float)_dateTime.DayOfWeek; } }
            // etc
        }

But the above code is not sufficient, because currently we require both getter and setter to be present (and public). So you have to add the fake setters that throw.

Is there a way to have it both ways somehow? We want to ensure that we'll be able to write to a property (in case when we use the underlying class as output), but we also want to allow read-only properties (in case when we use it as input).

@TomFinley , do you have a recommendation? I am leaning towards allowing getter-only (or private-setter) properties to live, but only for input classes. This means that SchemaDefinition / InternalSchemaDefinition should have some IsReadOnly tracking, and corresponding error/warning messages in case we attempt to generate a 'poke' method for a read-only property .

@TomFinley
Copy link
Contributor

Hi @Zruty0 seems like what you've suggested is good. Tracking and error if these read only properties (and fields!) acceptable for input with a copy to support the ref call seems good to me. We will want something like this for F# support for sure.

@shauheen shauheen added the API Issues pertaining the friendly API label Aug 6, 2018
@Zruty0
Copy link
Contributor Author

Zruty0 commented Aug 9, 2018

@TomFinley please take a look at #640 , I think this is good enough to be merged.

@ghost ghost locked as resolved and limited conversation to collaborators Mar 29, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
API Issues pertaining the friendly API
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants