cmd/compile: refactor access to Val values to use node methods #27212
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
For accessing e.g the string value of a node n that is a string literal the cmd/compile code base (walk.go, typecheck.go...) often uses
n.Val().U.(string)
. This exposes a lot of details about how constants and literals are implemented in the compiler to code that is mostly operating on nodes.Some types such as CTBOOL and CTINT already have node methods (
(n *Node) Bool()
and(n *Node) Int64()
) to extract the value the node represents.We can abstract away how values are represented with node methods and use these outside
const.go
instead of relying on the implementation details of how values are stored in nodes.All implementation details of how values are operated on inside nodes can be confined to const.go and the specific files for helper structures such as MpInt and MpFlt.
This should make the compiler code more readable, maintainable and help efforts to easier replace how the compiler stores and handles constants e.g. #4617.
Alternative
Instead of methods on the level of node they could be methods on the level of Val.
So instead of n.StringVal() for node n. It could be n.Val().StringValue().
This would keep the set of methods for operating on the subset of nodes with values separated instead of merging them into the pool of general node methods.
The downsides for the alternative would be:
cc @josharian @griesemer
The text was updated successfully, but these errors were encountered: