Skip to content

Commit b31c855

Browse files
committed
First draft
1 parent c5734a8 commit b31c855

File tree

2 files changed

+133
-0
lines changed

2 files changed

+133
-0
lines changed

docs/style-guide/README.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,6 +16,7 @@ languages that make up the Enso project.
1616
- [Rust](./rust.md)
1717
- [Haskell](./haskell.md)
1818
- [TypeScript](./typescript.md)
19+
- [Enso](./enso.md)
1920

2021
Our configuration and documentation also has style guides:
2122

docs/style-guide/enso.md

Lines changed: 132 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,132 @@
1+
---
2+
layout: style-guide
3+
title: Enso Style Guide
4+
category: style-guide
5+
tags: [style-guide]
6+
order: 7
7+
---
8+
9+
# Enso Style Guide
10+
11+
This style guide is aimed at developers writing Enso Libraries Code in the Enso
12+
language. It is not aimed at users writing Enso code via the graphical editor.
13+
14+
# Encapsulation
15+
16+
Encapsulation allows developers to present a consistent interface that is
17+
independent of its internal implementation. It is the foundation of reuseable
18+
"pieces" of code and funcationality. It allows other users (both internal and
19+
external) effectivley re-use components of your code.
20+
21+
# Types of Code Components in the Enso Langauge
22+
23+
In order to be able to talk about how we encapsulate components of code we first
24+
need to define what those components are. Enso has four levels of code
25+
components that can be built and shared with other developers. They are:
26+
27+
- Libaries
28+
- Modules
29+
- Types
30+
- Methods
31+
32+
TODO - defintion of each of these.
33+
34+
# Public verus Private
35+
36+
Now we have defined our components we need to look at how we define our public
37+
APIs for each of these and how we hide our private immplementations.
38+
39+
## Public
40+
41+
By default the Enso langauge is a very public one. If you don't use any of the
42+
private keywords and/or conventions described belown then everything is public.
43+
This is bad for encapsulation as other users and developers trying to re-use the
44+
code you wrote won't have a clean view of your code's API.
45+
46+
## Types of Private
47+
48+
There are a number of different ways to mark things Private in Enso
49+
50+
### Hidden from the Graphical Editor Private
51+
52+
This is acheived with the special PRIVATE keyword cotained in a comment above a
53+
type, constructor or method
54+
55+
e.g.
56+
57+
```
58+
## PRIVATE
59+
type Random_Generator
60+
```
61+
62+
or
63+
64+
```
65+
## PRIVATE
66+
Value (random_instance_holder:RandomInstanceHolder)
67+
```
68+
69+
or
70+
71+
```
72+
## PRIVATE
73+
set_seed self seed = self.random_instance_holder.setSeed seed
74+
```
75+
76+
This prevents a type, construstor ot method being used from the Component
77+
Browser inside of the graphical editor.
78+
79+
For other Enso code users it does not prevent its use and these are part of your
80+
components public API.
81+
82+
### Library Private
83+
84+
This is a langauge keyword `private` that can be used on modules, types, methods
85+
and constructors.
86+
87+
e.g.
88+
89+
TODO Examples.
90+
91+
This keyword makes whatever it marks private at the library component level and
92+
so is useful in defining the public and private parts of an Enso library. It is
93+
enforced by the compliler, so has a strong guarentee of enforcing the Public and
94+
Private parts of a library.
95+
96+
However for other developers working inside of the same library it does not
97+
prevent their use and these components are still part of your internal public
98+
API.
99+
100+
### Module Private
101+
102+
At the time of writing, the above is all the support the langauge has built-in
103+
for encapsulation. However as libary developers it is still important that we
104+
define Public APIs and Private implentations of our internal modules.
105+
106+
Which brings us to module private. This is "privacy by convention" and works by
107+
prefixing a method name with an underscore.
108+
109+
e.g.
110+
111+
```
112+
private _my_private_method
113+
```
114+
115+
Methods named like so are "Module Private". That is to say they should only be
116+
used within the module that they are defined in, and never from another module.
117+
118+
Only free methods should be named as such, and not methods on types.
119+
120+
Generally they should also be marked as Library Private using the ``private`
121+
keyword.
122+
123+
### Type Private
124+
125+
We do not have the concept of type private in the form of private methods or
126+
members that you might find in OO style languages. All members are public ouside
127+
of the type. Any methods that you wwant to be private should be pulled out of
128+
the type and made Module Private using the above convention.
129+
130+
# Some Concrete Examples
131+
132+
TODO

0 commit comments

Comments
 (0)