Giter VIP home page Giter VIP logo

Comments (4)

emil14 avatar emil14 commented on May 26, 2024 1

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.

emil14 avatar emil14 commented on May 26, 2024 1

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.

emil14 avatar emil14 commented on May 26, 2024

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.

emil14 avatar emil14 commented on May 26, 2024

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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.