I like the syntax of properties, like that they’re not the same as fields, and that I don’t have to export them. I’m considering switching from using accessor functions to properties in a large chunk of code, but I’m not sure it’s a good idea. Suppose I have struct S end. Is it okay to use under…

[image] sadish-d: I’d need to make sure that the existing names don’t conflict the user-defined names I don’t think they’ll change anytime soon, but technically those are internals, and custom field names that don’t conflict with them cannot be public because they can be broken arbitrarily. …

Sure, you can use _ as a field name so I don’t see why you couldn’t use it as a property name. Either case is kind of user unfriendly though, since property destructuring, (; _) = S(), puts your field into a write-only variable. 2-4. Don’t mess with properties of types you don’t own. (S is your…

[image] sadish-d: Is it okay to use underscores as property names? S()._ is currently valid syntax. Probably a bad idea. I’d swear there’s an issue in the context of #24990 where some argue that S()._ being allowed is a bug, an oversight from when _ variables became forbidden before 1.0, and …

[image] sijo: getproperty(::S, ::T) Did you mean getproperty(::Type{S}, ::T) here? getproperty(::S, ::Symbol) would not be type piracy, right? I think it’s starting to sink in that I don’t own Type{S} because I don’t own Type.

You could consider a wrapper around Type{S} that implements the properties you are interested in.

Wrapper as in a wrapper function, right? (still learning programming lingo). I think that’s what I have right now, mostly to get parameters from parametric types. So if S is parametric like S{D}, I have things like dims_of(::Type{S{D}}) where {D} = D.

[image] GunnarFarneback: You need to be very careful with only using getfield to access your real fields inside your getproperty and setproperty! implementations, to avoid performance traps. Could you tell me more about these performance traps? Is there even a way to access fields (not proper…

struct SType S::Type{S} end function Base.getproperty(ST::SType, s::Symbol) if s in propertynames(S) return getproperty(S, s) end return getproperty(ST, Val(s)) end

[image] mkitti: struct SType S::Type{S} end This throws UndefVarError: S not defined, field annotations unknowns must be from the type definition’s where clause.

Unsure about properties

General Usage

Topic		Replies	Views
Help with `Base.getproperty` syntax General Usage	7	3218	October 23, 2018
Overloading `getproperty` in a type-stable manner General Usage question	4	2119	March 28, 2020
Recommended approach for getproperty shadowing General Usage question	3	546	December 5, 2018
Better documentation for properties vs. fields Internals & Design documentation	7	1099	September 16, 2021
What's the difference between fields and properties? General Usage question	8	6445	March 23, 2020

Unsure about properties

Related topics