You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was just watching the Toy DOM video and one of the complaints Andreas mentioned was needing to make some of the members public because they need to be read outside of the class. Explicit getters/setters are one way around this, but support isn't there yet (see ~15:35 in the aforementioned video), and also I personally find they clutter the code quite a bit.
Instead I would like to propose another feature copied from Swift: the ability to mark a member as being publically gettable, but only privately settable. The Swift syntax for this is private(set) (docs), but I've always found that syntax a bit confusing, so I'm open to other suggestions. Doing it this way allows the best of both worlds: the access of the member is a pure reference, so no extra tracking is needed, but only the class is allowed to modify the value.
Here is an example of the Text node from the start of the video ported to Swift:
classText{private(set)vardata:Stringinit(data:String){self.data = data
}}lettext=Text(data:"Hello, world!")print(text.data)// "Hello, world!"
text.data ="Hello, world!"// Error: Cannot assign to property: 'data' is a private(set) property
The text was updated successfully, but these errors were encountered:
I was just watching the Toy DOM video and one of the complaints Andreas mentioned was needing to make some of the members public because they need to be read outside of the class. Explicit getters/setters are one way around this, but support isn't there yet (see ~15:35 in the aforementioned video), and also I personally find they clutter the code quite a bit.
Instead I would like to propose another feature copied from Swift: the ability to mark a member as being publically gettable, but only privately settable. The Swift syntax for this is
private(set)
(docs), but I've always found that syntax a bit confusing, so I'm open to other suggestions. Doing it this way allows the best of both worlds: the access of the member is a pure reference, so no extra tracking is needed, but only the class is allowed to modify the value.Here is an example of the Text node from the start of the video ported to Swift:
The text was updated successfully, but these errors were encountered: