ASM Bytecode Generation to unwrap Expressions of adv-expr API #94
No reviewers
Labels
No Label
bug
dependencies
discussion
documentation
duplicate
feature
good first issue
misc
performance
question
test
use case
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: kscience/kmath#94
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "adv-expr"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I think that the main problem is the exposed design. The
AsmGenerationContext
should be made private or internal and hidden from the user. Also I think that produced entities should inheridExpression
so this functionality is compatible with functional implementation.Probably should be implementation
Add suppress for unused parameters and documentation.
Space is not actually used.
Not used
@ -0,0 +1,139 @@
package scientifik.kmath.expressions
The rename is meaningless since there is no class with that name. FunctionalExpressionAlgebra is acceptable though.
@ -0,0 +1,23 @@
package scientifik.kmath.expressions
There is no class called
Builders
. I suggest starting the name with lower case letter.Add documentation since the interface is public.
@ -0,0 +1,23 @@
package scientifik.kmath.expressions
This is a violation of Coding Conventions.
does it make sense to do invoke without
operator
? It seems that it should be renamed tocompile
. Those method need to be documented as well.OK
OK
It seems like
compile
is a better name.Could the constructor be made internal?
I'll check
rename to
asmBuilders
Source file names have to be started with upper-case letter. https://kotlinlang.org/docs/reference/coding-conventions.html#source-file-names
I'll rename to AsmBuilders
This method should never be made public, the whole compilation chain: creation of the context, invokation of expression and generation should hidden from API in order to avoid leaking of unfinilized AsmGenerationContext.
OK
It can.
I suggest to bundle all misc methodsin one file or create
internal
directory for them to limit their visibility.@ -0,0 +1,23 @@
package scientifik.kmath.expressions
Yes, but there are some variations of file naming accepted by the communitiy. And there is a style that is used accross other modules, so we need to keepr it uniform. I will write a doc file with local conventions.
OK