Treat primitives and their autoboxed types as one and the same
See original GitHub issueFollowing on from this comment:
I think we should treat Integer and int as one type.
Each instance of a primitive and its respective autoboxed type should count as the same type. For example:
public String doSomething(int id, Integer other);
We should coalesce int
and Integer
into a single type for analyses, so our metrics should calculate the total parameter types (both input and output) for this method as 2 instead of 3.
Issue Analytics
- State:
- Created 6 years ago
- Comments:28 (19 by maintainers)
Top Results From Across the Web
Java: Understanding Primitive Types and Wrapper Objects
Introduced in Java 5.0, Autoboxing is the automatic conversion of primitive types to their corresponding object wrapper classes.
Read more >Autoboxing and Unboxing in Java
In Java, primitive data types are treated differently so do there comes the introduction of wrapper classes where two components play a role ......
Read more >When to use primitive and when reference types in Java
In which case should you use primitive types( int ) or reference types ( Integer )? ... Autoboxing will turn "1", "2", "3"...
Read more >How To Use Autoboxing and Unboxing in Java Programming
Primitive types are simple atomic, and their corresponding wrapper classes are heavy. Also, any conversion, even an automatic one, always needs ...
Read more >Autoboxing and Unboxing
Autoboxing is the automatic conversion that the Java compiler makes between the primitive types and their corresponding object wrapper classes.
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 Free
Top 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
@llorllale @amihaiemil how about we create one more layer between
skeleton.xml
andLCOM.xsl
, which will include a number of XSL stylesheets. One stylesheet will merge/coalesce types. Another one will remove ctors. Another one will remove static methods, and so on. That will help us get rid of code duplication inside XSL and will make the entire architecture composable: we can use certain XSL layers or ignore them. WDYT?@llorllale @amihaiemil I fixed the puzzle in #166 and removed it from the source code. Now we have XSL layers. We have just two of them: for removal of ctors and remove of static methods. If you need more, feel free to report bugs/tickets.