Comments (4)
Introduce DI
import: # imports must be resolved first
pkg1: path/to/pkg # external package
pkg2: "@/path/to/pkg" # package from same mod (proj/space)
io: # args (generics) may be omitted
in:
a: pkg1.externalType # reference to type from external package
b: pkg2.externalType
c: localType # reference to type in types.yaml in same folder
# di means this component must be initiated before use - it must get its deps
di: # di and import are sources of what workers may refer to
dep1: pkg1.externalInterface
dep2: pkg2.externalInterface
dep3: localInterface # defined in types.yml in same folder (or *.t.yml files?)
workers: # components instances to do work in the network
w1:
ref: pkg1.externalComponent
w2:
ref: pkg1.externalComponentWithDI
di:
dep: pkg1.externalComponent # di in action
Problems
- DI usually happens in a single specific place. Wouldn't it be better to implement some framework for that (introduce some
di.yml
) instead of add this logic to component level- In languages like Go/JS/Python we see something more like this peace of yaml. It's probably possible to implement framework on top of this but not vice versa
- Implementation must be very good thought of
from neva.
DI, direct refs to imports, io as part of nodes, pkg scoped interfaces
After compilation (before translating) program could look like this
program:
root: users
pkgs:
users:
imports: [std/strings, humans]
types: # `bool, int, float, str, sig, map, list, maybe` - reserved words (builtin types)
user:
id: int
human: humans.human
friends: list<user>
bestFriend: maybe<user>
mapExample: map<user> # only type references (not defs) (with generic args) allowed
interfaces:
stringer<T>: # if regexp.MatchString(s, `.+<(.\,*)+>`) {}
in:
in: T
out:
out: str
components:
root:
di:
stringer0: stringer
stringer1: std/strings.stringer
nodes:
io<T>:
in:
run: sig # alias for empty struct (or use any?)
out:
bar: str
static: # const
foo:
type: user
value: #?
human:
age: 42
name: "john"
friends: []
bestFriend: null
component: # workers
stringer0: di.stringer0 # di ref 1
stringer1: di.stringer1 # di ref 2
stringer2: import.std/strings.defaultStringer # direct ref
net:
in.foo:
- component.stringer0
- component.stringer1
- component.stringer2
component.stringer0: out.bar
component.stringer1: out.bar
component.stringer2: out.bar
root: root
humans:
types:
human:
age:
ref: int
name:
ref: string
exports:
types:
- human
std/strings:
interfaces:
stringer:
args: [T]
in:
in: T
out:
out: str
components:
defaultStringer: ...
from neva.
Complex components use direct import
imports:
dep: path/to/package # every import has an alias
io:
in:
a: dep.ExternalType # reference to imported type
out:
b: dep.ExternalType
nodes:
workers:
w1: asIs # local imports not are not defined in `imports`
w2: dep.asIs
net:
in.a:
- w1.a
w1.b:
- w2.a
w2.b:
- out.b
Problems
Interfaces
What looked like a genius idea now left behind completely. In conventional programming functions can take interface values to do build structures. Here ports takes only data. How to depend on interface?
from neva.
Interfaces as deps
Modified version of a previous comment. Let's add interfaces to the picture
deps:
import: # direct
dep1: modref/path/to/package
interface: # indirect
dep2:
ref: localInterface
dep3:
ref: dep1.externalInterface # like os.Writer
Problems
- UI Inconsistency - we directly depend on packages but indirectly depend on interfaces (package entities)
from neva.
Related Issues (20)
- Closure (Implement "visibility scope" via hierarchy of deferred connections) HOT 1
- [Idea]: Should we write Runtime funcs to use one Goroutine per port? HOT 4
- Multiline Comments HOT 2
- Inconsistent output inside `For` with branching HOT 7
- Match allows array-port overwrite HOT 1
- Consistent naming for boolean components
- Alternative syntax for outports HOT 3
- `Zip` component HOT 2
- Iter should support strings HOT 1
- Race-condition with fan-in pattern HOT 2
- Force Outport Operator HOT 3
- Data processing components out of the box
- `Find` component HOT 1
- `Has` component HOT 1
- `Collate` component
- Reduce noise when using ports by replacing `:` with `.` HOT 1
- HTTP Client
- Improve struct field selectors syntax
- Move println to io HOT 2
- Reduce as higher order component for binary handlers HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from neva.