The argument could go in either direction. Perhaps the right thing to do would be to change get and set to read and write. The guidance you're talking about was provided by the same people who disallowed set-only properties in the first place.
I don't know a lot about Metal specifically, but it seems that the class you pointed to encodes commands into a command buffer. I would think that it's a pretty good example of a place where methods need to stay methods. It's generally a violation of the principle of least surprise when something like:
foo.a = 4
foo.a = 5
isn't the same as just `foo.a = 5`.
Félix
···
Le 3 févr. 2016 à 16:49:02, Jessy Catterwaul <mr.jessy@gmail.com> a écrit :
C# still hasn’t gotten named subscripts or tuples. It is not the place to go to look for what Swift should be. It’s just the only place I’ve had access to set-only properties, and because much of what I was doing was feeding data to GPUs, set-only properties made a lot of sense, frequently.
The most important thing is to not consider setting “writing”, or getting “reading”. Properties and subscripts are specifically “get” and “set”, and don’t enforce reading or writing any state. The book even gets the terminology wrong, as “read-only” instead of “get-only": The Swift Programming Language: Redirect
I understand that there is a lot of history in thinking about getters and setters as having something to do with storage, but that we have the keywords “get” and “set”, and not “read” and “write”, is guidance for cleaner APIs.
On Feb 3, 2016, at 4:34 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@yahoo.ca>> wrote:
I would find a list of actual C# set-only properties more relevant. It wouldn't make sense for a lot of these "set-only properties" in there to offer only a setter if they were made into properties.
In general, I consider properties to be the observable state of an object. When I write something to a property, I expect to be able to get it back. When I pass something as a method parameter, I don't expect that I'll be able to get it back later.
Félix
Le 3 févr. 2016 à 16:02:41, Jessy Catterwaul via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
I do not agree about the implication. A property can be gotten, set, or both, in at least C#, where I used a ton of set-only properties.
Here is a large list of properties that are set-only:
MTLRenderCommandEncoder | Apple Developer Documentation <MTLRenderCommandEncoder | Apple Developer Documentation;Some of them require more than a single value, for setting. Tuple assignment or named subscripts are the best way I currently know to handle that. Having them be functions that begin with “set” and take arguments feels archaic and not specific enough, to me.
func setStencilFrontReferenceValue(frontReferenceValue: UInt32,
backReferenceValue: UInt32
)
setStencilFrontReferenceValue(0, backReferenceValue: 1)versus
var stencilReferenceValues: (front: UInt32, back: UInt32) {set}
stencilReferenceValues = (front: 0, back: 1)func setVertexSamplerState(sampler: MTLSamplerState?, atIndex index: Int)
setVertexSamplerState(someState, atIndex 0)versus
subscript vertexSamplerState(index: Int): MTLSamplerState? {set}
vertexSamplerState[0] = someStateThe former options, I feel are not Swift, but C masquerading as Swift.
> Cc:swift-evolution@swift.org <mailto:evolution@swift.org>
> Subject:[swift-evolution] Support for pure setters
> Date:February 3, 2016 at 3:31:16 PM EST
>
>
>
> > On Feb 3, 2016, at 12:21 PM, Jessy Catterwaul<mr.jessy@gmail.com <mailto:mr.jessy@gmail.com>>wrote:
> >
> > Joe, to attempt to set foo.x doesn’t make sense. If foo cannot be gotten, a property of it will be inaccessible for getting or setting.
> >
> > Set-only properties are always computed, and only used via assignment.
> >
> > e.g. foo = value
> I understand that. If that's all you're allowed to do with a set-only property, then this is just sugar over 'setFoo(value)', and I think the sugar implies you could do more with 'foo' than you really can. I don't think it's worth the complexity.
>
> -Joe
>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution