[Open Discussion] New source attribute naming convention for 3.0
See original GitHub issueCurrently in version 2.3.0b, source objects have their attribute names written out in full: Example from the magnet box source.
.magnetization
Magnetization vector of box in units of [mT].
.dimension
Magnet dimension=[a,b,c] which correspond to the three side lengths of the box in units
.position
Position of the center of the magnet in units of [mm].
.angle
Angle of orientation of the magnet in units of [deg].
.axis
Axis of orientation of the magnet.
The API for the constructor currently makes use of keywords such as mag
, dim
, pos
, angle
, axis
to set the value for these attributes.
In the upcoming 3.0.0 release, it has been suggested to shorten all the attribute names to match the API. We’re also introducing a new relative position attribute regardless, which replaces both axis
and angle
. The current proposal for the attribute names is as follows:
.mag
Magnetization vector of box in units of [mT].
.dim
Magnet dimension=[a,b,c] which correspond to the three side lengths of the box in units
.pos
Position of the center of the magnet in units of [mm].
.rot
Present relative rotation of the magnet, returns a scipy rotation object.
It would be nice to have an open discussion with both developers and users to conclude whether this naming proposal is preferable over the new one, or to have the new proposals that may combine the qualities of both.
Issue Analytics
- State:
- Created 3 years ago
- Comments:12 (8 by maintainers)
Top Results From Across the Web
Bus naming array - OpenDSS / Discussion / Beginners
Therefore, I will be creating a new thread to ask it. When defining a single phase transformer terminal connections as an array as...
Read more >Naming convention (programming) - Wikipedia
In computer programming, a naming convention is a set of rules for choosing the character sequence to be used for identifiers which denote...
Read more >Entity Framework complex type's columns naming convention
For some of complex types I would prefer do not mention property name ("Contact") at all for others connect name and attribute using...
Read more >[Discussion] Async suffix for controller action names will be ...
Adding magic to change names seems like a source of bugs. There's no reason to use the async suffix in the first place...
Read more >What "version naming convention" do you use? [closed]
It is a public specification for a versioning scheme, in the form of [Major]. ... version to changes that occurred in the source...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I like to make my names just verbose enough to not be ambiguous. Would vote for short form in this case. I also prefer
.orient
over.rot
although it breaks the nice 3 letter pattern. Can’t have everything.API backward compatibility is not a valid concern to me for a least two reasons. They’re already breaking it by merging
.angle
and.axis
as mentioned in OP. I expect to see some more breaking changes throughout new code (didn’t look). The other reason is convention. Bumping major version number (2.x.x -> 3.x.x) implies API change, which is probably a very conscious and well thought out decision by the authors. On the contrary, it would be very wrong if name change was delayed to any minor version update.completed with #330