Как создать ссылку на метод из массива-свойства структуры в Go?

Question

[Roman]

Стоит задача, сделать в Go такую структуру, одним из свойств которой, был бы массив или карта, с указателями на методы (т.е функции, исполняемые именно в контексте экземпляра структуры). А так же был бы метод, вызывая который и передавая в него идентификатор массива (карты) можно было бы вызвать метод, который мог бы работать со свойствами

Язык для меня новый, нагуглить не смог совсем.

Для примера, тоже самое, но на JavaScript

class Test {
    constructor() {
        this._a = 0;
        this._b = 0;
        // Список указателей на методы
        this._fn = new Map();
        this._fn.set(0x00, this._add);
        this._fn.set(0x01, this._sub);
    }

    init(a, b) {
        this._a = a;
        this._b = b;
    }

    _add() {
        return this._a + this._b;
    }

    _sub() {
        return this._a - this._b;
    }

    call(fnID) {
        const fn = this._fn.get(fnID);
        if (!fn) {
            throw new Error('Bad function ID');
        }
        return fn.apply(this);
    }
}

const t = new Test();
t.init(2, 5)
console.log(t.call(0x00), t.call(0x01));

// Результат выполнения: 7 -3

Answer 1

[Roman]

Ниже тоже самое на Go, но без карты методов, а хотелось бы как-то красивее:

package main

import "fmt"

// Test structure
type Test struct {
	a       int8
	b       int8
	opcodes [2]func() int8
}

func (t *Test) add() int8 {
	return t.a + t.b
}

func (t *Test) sub() int8 {
	return t.a - t.b
}

// Init properties
func (t *Test) Init(a, b int8) {
	t.a = a
	t.b = b
	// Вручную заполняем указатели на методы
	t.opcodes[0] = t.add
	t.opcodes[1] = t.sub
	return
}

// Call method by ID
func (t *Test) Call(fnID int8) int8 {
	fn := t.opcodes[fnID]
	if fn == nil {
		panic(`Empty command`)
	}
	r := fn()
	return r
}

func main() {
	t := new(Test)
	t.Init(2, 5)
	fmt.Println(t.Call(0x00), t.Call(0x01))
}

UPD: Убрал switch, добавил массив. Соотвественно вопрос: можно ли сделать так, чтобы при создании экземпляра, автоматом заполнялся массив Test.opcodes указателями на методы

Comments

[Александр Павлюк]

В го принято конструктор делать в виде функции NewSomething

func NewTest(a, b int8) *Test {
    t := &Test{
        a:a,
        b:b,
    }
    t.opcodes[0] = t.add
    t.opcodes[1] = t.sub
    return t
}

Answer 2

[Александр Павлюк]

Не пытайтесь тащить стиль скриптовых языков в го. Здесь другой стиль и другой подход.
Лучше просто писать на джаваскрипте, чем пытаться сделать из го джаваскрипт.

Comments

[Roman]

На ноде с использование WorkerThreads 40000 подобных объектов с 65 подобными методами выжирают довольно много ресурсов. А Go мне интересен и интересно как он будет их потреблять. И я не стремлюсь тащить что-то куда-то. Но и ответ на вопрос найти не получилось. Впрочем так как конструкторов Go не имеет, видимо единственно возможный способ гарантированно заполнить массив ссылками, это сделать обязательный к вызову метод. Или вызывать его самому, сделав доступным вне пакета где описывается структура, одну функцию, которая вернёт инициализированную структуру (выполнив перед эти этот метод)

func Create(a, b int8) *Test {
  t := new(Test) 
  t.Init(a, b) 
  return t
}

[Александр Павлюк]

Roman, именно потому и выжирает много ресурсов, что там это динамическая структура.
Зачем вам именно динамическая мапа со ссылками на функции? Какую задачу вы этим пытаетесь решить? Чем не подходят статические методы?

[Roman]

В оригинале структура состоит из массива opcodes, содержащий байткод простенькой стековой машины. Код генерируется пользователем по своему усмотрению, но с учетом ограничений инструкций стековой машины. При наступлении определенных событий (входящие данные), если эти данные для этого экземпляра структуры, дергается метод Run, который пробегает по байтам и в зависимости от того, какое значение там записано, дергает нужный метод и использует входящие параметры. Мапа тут не причем, функции вполне себе определены изначально и могут быть помещены в массив. От стековой машины отказаться нельзя, это обязательное условие. Сделать статические функции, которым передавался бы нужная структура для обработки - можно. А это правда нужно, учитывая необходимость параллельной обработки? В ноде я хоть миллион однотипных объектов создам, методы будут существовать только в единственном экземпляре, а вот ссылки на их области видимости внутри объекта - уникальные, каждая на себя . Предполагаю что и в Go методы работают так же.

[Александр Павлюк]

Roman, Прошу прощения, сначала неверно понял. Думал, что вы пытаетесь реализовать динамические методы у самих классов, как в js.
Сейчас примерно понял задачу, но не понял зачем в классе Test хранятся и поля a, b и указатели на методы? При этом, методы заполняются каждый раз при создании Test. Почему нельзя сделать некий один общий объект, который хранит маппинг опкодов на методы, а в Test оставить только a и b?

И что вы понимаете под "картой методов"? Если ассоциативный массив, то в го он называется map.
opcodes map[int8]func() int8

[Roman]

После сегодняшних прочтений, уверен что карта (map) - не нужна. Мне не требуется динамически добавлять и удалять методы. Они заранее определены. По этому массив (слайс на него как указатель) - максимально быстрое решение. .a и .b - это просто пример, чтобы показать, что методы, работают со свойствами.

Вот оригинальный пакет с незаполненными методами стековой машины:

package vm

import "fmt"

const memSizeFlash = 255
const memSizeRAM = 64
const memSizeStack = 64

// VMachine - vurtual machine structure
type VMachine struct {
	flash   [memSizeFlash]uint8 // ROM array
	ram     [memSizeRAM]uint8   // RAM array
	stack   [memSizeStack]int32 // Stack array
	PC      uint16              // Programm counter
	SC      uint16              // Stack counter
	IR      uint16              // Interrupt address
	opcodes [128]func() bool    // Pointers on methods
}

func (v *VMachine) tick() bool {
	funcID := v.flash[v.PC]

	next := v.opcodes[funcID]()
	fmt.Println(funcID, next, v.PC)
	v.PC++
	return next
}

func (v *VMachine) init() {
	v.opcodes[0x00] = v.oFin
	v.opcodes[0x01] = v.oNoop
}

// Load new bytecode to flash and reset registers
func (v *VMachine) Load(opcodes []uint8) {
	v.init()
	flash := v.flash[:]
	copy(flash, opcodes)
	v.PC = 0x0000
	v.IR = memSizeFlash - 1
	return
}

// Interrupt ticks and call interrupt function
func (v *VMachine) Interrupt() {
	return
}

// Run algorithm
func (v *VMachine) Run() {
	for {
		next := v.tick()
		if !next {
			break
		}
	}

	fmt.Println(v.flash)
	return
}

func (v *VMachine) oFin() bool {
	return false
}

func (v *VMachine) oNoop() bool {
	return true
}

При создании нового экземпляра, в обязательном порядке используется Load(для передачи слайса на массив байт-кода). Там же я вызываю .init для установки указателей на методы. Хотелось бы сделать это автоматически при new(VMachine)

[falconandy]

Можно попробовать использовать reflect, но нужно оценить накладные расходы:
https://play.golang.org/p/S2aJuFwbQAq

Еще можно попробовать с помощью go generate и парснига кода структуры генерировать в отдельном файле метод fillOpCodes(), который будет вызываться из метода Init структуры.

[Александр Павлюк]

falconandy, я все еще не понимаю, зачем заполнять массив опкодов при создании каждой виртуальной машины. Если опкоды статические и не меняются, их надо вынести в отдельный пакет и сделать там глобальной переменной. Заполнять при старте приложения и всё!

[falconandy]

Александр Павлюк да, если делать через go generate можно так:

Основной файл:

package main

import (
	"fmt"
)

var (
	opCodes []func(t *Test) int8
)

type Test struct {
	a int8
	b int8
}

func (t *Test) Add() int8 {
	return t.a + t.b
}

func (t *Test) Sub() int8 {
	return t.a - t.b
}

func (t *Test) Call(fnID int) int8 {
	return opCodes[fnID](t)
}

func main() {
	t := Test{
		a: 2,
		b: 5,
	}
	fmt.Println(t.Call(0x00), t.Call(0x01))
}

Сгенерированный файл:

package main

func init() {
	opCodes = make([]func(t *Test) int8, 2)
	opCodes[0] = func(t *Test) int8 {
		return t.Add()
	}
	opCodes[1] = func(t *Test) int8 {
		return t.Sub()
	}
}

[falconandy]

А если методы в структуре вообще не нужны сами по себе, то совсем по-простому:

package main

import (
	"fmt"
)

var (
	opCodes []func(t *Test) int8
)

func init() {
	opCodes = make([]func(t *Test) int8, 2)
	opCodes[0] = func(t *Test) int8 {
		return t.a + t.b
	}
	opCodes[1] = func(t *Test) int8 {
		return t.a - t.b
	}
}

type Test struct {
	a int8
	b int8
}

func (t *Test) Call(fnID int) int8 {
	return opCodes[fnID](t)
}

func main() {
	t := Test{
		a: 2,
		b: 5,
	}
	fmt.Println(t.Call(0x00), t.Call(0x01))
}

[Александр Павлюк]

falconandy, тут и generate не нужен. Легче просто заполнить один раз массив вручную.
Я бы сделал так:

func init() {
	opCodes = []func(t *Test) int8{
		// Add
		func(t *Test) int8 {
			return t.a + t.b
		},
		// Sub
		func(t *Test) int8 {
			return t.a - t.b
		},
	}
}

[falconandy]

Александр Павлюк чуть выше у меня такой же вариант, только заполнение массива некрасивое и без поясняющих имен

[Roman]

Александр Павлюк, я не вполне уверен что это верно для Go, но в js это будет создавать массивы с функциями для каждого экземпляра структуры (объекта в жс) , а в моем варианте - массив со ссылками на функции, которые скомпилированы в единичном экземпляре.

[Александр Павлюк]

Roman, нет, как раз в вашем варианте го будет создавать слайс с функциями для каждого экземпляра структуры, ибо вы заполняете этот слайс данными в конструкторе.
У меня же слайс заполняется данными один раз при старте приложения, а дальше переиспользуется всеми экземплярами.

[Roman]

Александр Павлюк, Да, точно спасибо. Вечно забываю что в Go всегда копирование...

[Александр Павлюк]

Roman, в го всегда именно то, что написано в коде. Если в коде создается новый слайс при создании экземпляра, то и будет создаваться новый слайс.
Копирование в го не всегда, если кладете указатель, то и кладется указатель. Если кладете значение, но копируется значение.