| ... | ... | @@ -36,9 +36,11 @@ reference: |
|
|
|
|
|
|
|
There are a few things that should probably be clarified by the language definition dealing with field names and class methods, not that there is debate but they should be clearly specified:
|
|
|
|
|
|
|
|
1. does exporting a class name and a method name seperately as a function allow it to be declared in instance declarations? or does the function name need to be exported as part of a subordinate list?
|
|
|
|
- does exporting a class name and a method name seperately as a function allow it to be declared in instance declarations? or does the function name need to be exported as part of a subordinate list?
|
|
|
|
|
|
|
|
1. the field name and function namespaces are different and export/import rules should take this into account, declaring fields creates _both_ a function and a field name. so should exporting the function also export the field name? or should the field name only be exportable via a subordinate list?
|
|
|
|
- the field name and function namespaces are different and export/import rules should take this into account, declaring fields creates _both_ a function and a field name. so should exporting the function also export the field name? or should the field name only be exportable via a subordinate list?
|
|
|
|
|
|
|
|
|
|
|
|
Some compilers distinguish these namespaces, others do not.
|
|
|
|
|
|
|
|
- We also may wish to specify recursive module behavior now that the work at formalizing the rules has been done in the previous paper. jhc and helium both implement the algorithm as given to good effect. |
