AleoHQ/leo
1
1
Fork 0
mirror of https://github.com/AleoHQ/leo.git synced 2024-12-25 18:42:26 +03:00
Code Issues Packages Projects Releases Wiki Activity

grammar fixes

Browse Source
This commit is contained in:
damirka 2021-06-23 13:07:44 +03:00
parent 7b150f3a19
commit 1083fc80c2
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
docs/rfc/003-imports-stabilization.md
View File

@ -17,11 +17,11 @@ DRAFT
# Summary
This proposal aims to improve import management system in Leo programs to
This proposal aims to improve the import management system in Leo programs to
make program environment more reproducible and predictable. To achieve that
we suggest few changes to Leo CLI and Manifest:
- add "dependencies" section to Leo Manifest and add command to pull those dependencies;
- add a "dependencies" section to Leo Manifest and add a command to pull those dependencies;
- allow custom names for imports to manually resolve name conflicts;
- store imports as they are called in Leo Manifest;
@ -33,9 +33,9 @@ imported packages based on both their contents and version.
What problems does it solve? What is the background?
Current state:
- imports are published with program to Aleo PM;
- we treat program as files with no verification of imports (they can be changed locally and published in that state);
- name collisions cannot be resolved; new import overwrites existing;
- imports are published with a program to Aleo PM;
- we treat programs as files with no verification of imports (they can be changed locally and published in that state);
- name collisions cannot be resolved; a new import overwrites existing;
TBD
@ -73,7 +73,7 @@ same name but different authors. To resolve name conflict we suggest storing
imports as they are named in Leo Manifest file (Leo.toml).
<!-- Suggested change is soft. It changes only the way imports are organized
<!-- The suggested change is soft. It changes only the way imports are organized
with minimal changes to other parts of the language.
We can consider implementing imports/username-package storage, but imports
@ -81,19 +81,19 @@ will have to be resolved on a different level in compiler. -->
# Drawbacks
This change might require update of already published programs on Aleo PM due to
This change might require the update of already published programs on Aleo PM due to
Leo Manifest change. However it is possible to implement it in a backward-compatible
way.
# Effect on Ecosystem
Proposed improvement provides safety inside Leo programs and should not affect
ecosystem except for tools which use Leo directly (such as Aleo Studio).
ecosystem except for the tools which use Leo directly (such as Aleo Studio).
It is possible that some of the proposed features open new features on Aleo PM.
It is possible that some of the proposed features will open new features on Aleo PM.
# Alternatives
Another approach to stated cases is to keep everything as we have now but change
Another approach to the stated cases is to keep everything as we have now but change
the way programs are imported and stored and make names unique. Also, current
implementation provides some guarantees on import stablitity and consistency.