Skip to content

Commit

Permalink
Documentation: add class comments
Browse files Browse the repository at this point in the history
  • Loading branch information
guillep committed Oct 1, 2019
1 parent 09fb83d commit 81893e0
Show file tree
Hide file tree
Showing 5 changed files with 29 additions and 0 deletions.
3 changes: 3 additions & 0 deletions src/UnifiedFFI/FFIClassVariableArgument.class.st
@@ -1,3 +1,6 @@
"
I am a loader for class variables, pushing to the stack the class variable literal
"
Class {
#name : #FFIClassVariableArgument,
#superclass : #FFIFunctionArgumentLoader,
Expand Down
7 changes: 7 additions & 0 deletions src/UnifiedFFI/FFIConstantArgument.class.st
@@ -1,3 +1,10 @@
"
I am a function argument representing a literal value (in contrast to a variable).
The parser creates me when it finds other than symbols as arguments.
I am resolved by resolving my type.
The type knows how to resolve itself in a context.
"
Class {
#name : #FFIConstantArgument,
#superclass : #FFIFunctionArgument,
Expand Down
4 changes: 4 additions & 0 deletions src/UnifiedFFI/FFITypeDeclaration.class.st
@@ -1,3 +1,7 @@
"
I represent a type declaration in a FFI function signature. I have a type name and an arity (the number of indirections indicated by pointer marker stars *).
I am resolved as an external FFI type with my arity.
"
Class {
#name : #FFITypeDeclaration,
#superclass : #Object,
Expand Down
7 changes: 7 additions & 0 deletions src/UnifiedFFI/FFIUndefinedTypeDeclaration.class.st
@@ -1,3 +1,10 @@
"
I represent the absense of a type declaration.
I delegate my resolution to the resolver with a double dispatch so it can choose how to resolve non-declared types.
A resolver (FFICallout) has two main resolution strategies:
- strict does not accept resolving undefined types
- non strict is a backwards compatibility mode that tries to infer the type if possible (but can go wrong and should be used with care)
"
Class {
#name : #FFIUndefinedTypeDeclaration,
#superclass : #Object,
Expand Down
8 changes: 8 additions & 0 deletions src/UnifiedFFI/FFIVariableArgument.class.st
@@ -1,3 +1,11 @@
"
I am a function argument representing a variable (in contrast to a literal value).
The parser creates me when it finds symbols as arguments.
I am resolved by resolving my type and my name.
The type knows how to resolve itself in a context.
To resolve my name, the resolver performs a semantic analysis in the calling context to define if the variable is an instance variable, a method argument or a class variable. The name resolution is represented by my loader.
"
Class {
#name : #FFIVariableArgument,
#superclass : #FFIFunctionArgument,
Expand Down

0 comments on commit 81893e0

Please sign in to comment.