feat: event & emit in gno

[anarcher]

Description

This is an implementation PR for #575.
I think Events can be indexed by indexers by default, so I think they should be a structured data type, unlike logs.
In the future, #546 will allow us to view events directly. For now, I think it would be helpful for debugging to be able to view events when doing a gnokey maketx call, like this :

$ gnokey maketx call -config ~/tmp/maketx.local.toml  -pkgpath "gno.land/r/test/event5" -func "Hello"  -broadcast  anarcher
Enter password.
("hello world!" string)
OK!
GAS WANTED: 2000000
GAS USED:   111997
EVENTS:   [type: gno-hello, attributes: [[world: hello world! foo: bar sender: g1ts24jjaxvqjcskdbqzu24r9e4n62ggye520ocv5]

Here's an example of its use in gno

package event

import "std"

const EventAttrKeySender = "sender"


func Hello() string {

     std.EmitEvent("hello",
             "world", "hello world!",
             "foo", "bar",
             EventAttrKeySender, string(std.GetOrigCaller()),
     )
     
     return "hello world!"
}

Contributors Checklist

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests

Maintainers Checklist

• Checked that the author followed the guidelines in CONTRIBUTING.md
• Checked the conventional-commit (especially PR title and verb, presence of BREAKING CHANGE: in the body)
• Ensured that this PR is not a significant change or confirmed that the review/consideration process was appropriate for the change

[moul]

What about an API like this instead:

package event

import "std"

type helloEvent struct {
	World string
	Foo string
	Nb int
}


func Hello() string {
	std.Emit("hello", helloEvent{
			World: "yellow world",
			Foo: "bar",
			Nb: 42,
	}

	return "hello world!"
}

[anarcher]

I think it's an interesting interface :-)
Personally, I don't think there's much need to leave the event UX flexible (I hope there's not a lot of logic and exceptions and processing costs in event handling) (more personally, I hope contract authors(included me) don't create a lot of events haha :-)
If we get a custom event based on Struct, at least we should make this custom event amino encodable/decodable (I don't know how to do that yet), or we should convert the gno-defined event to an AttributedEvent (which is included in amino in this PR).
And I would like the event itself to have only a type for the event and one-dimensional key-value data (I don't think there is much value to be gained from complex nested (multidimensional) data, neither for reading nor for indexing). I also think it would be more useful if all events were of the same structure (a list of one-dimensional key-value types).

However, if we think the above design is more useful, we could probably create it with some limitations(which is probably hard to express in code?). :-)

[harry-hov]

I think the event API introduced in this PR is good. It looks more familiar to cosmos.

[anarcher]

What if we provided evnet.AddAttribute()?

helloEvent := std.NewEvent("hello")
helloEvent.AddAttribute("world", "hello world!")
helloEvent.AddAttribute("foo", "bar")

std.EmitEvent(helloEvent)

[jaekwon]

So many options.

What if we provided evnet.AddAttribute()?

helloEvent := std.NewEvent("hello")
helloEvent.AddAttribute("world", "hello world!")
helloEvent.AddAttribute("foo", "bar")

std.EmitEvent(helloEvent)

I like this.
NewEventAttribute seems cumbersome to use. It would be easier to have Emit(type, attrs... string) and split even/odd.
But alternatively I like the above AddAttribute approach. Either way, without the need to expose the EventAttribute type.

[jaekwon]

see above comment

[anarcher]

I like this.
NewEventAttribute seems cumbersome to use. It would be easier to have Emit(type, attrs... string) and split even/odd.
But alternatively I like the above AddAttribute approach. Either way, without the need to expose the EventAttribute type.

I agree. Added Event.AddAttribute(). I'm also going to add std.NewEvent(type string, attires... string), and I think it would be fine to support both.

[anarcher]

I changed it to the following interface.

NewEventAttribute seems cumbersome to use. It would be easier to have Emit(type, attrs... string) and split even/odd.

const EventHello = "hello"
const EventAttrKeySender = "sender"

std.EmitEvent(EventHello,
                "world", "hello world!",
                "foo", "bar",
                EventAttrKeySender, string(std.GetOrigCaller()),
)

I think this interface concise and useful too . Thank you, jaekwon.

[zivkovicmilos]

@anarcher
Closing this PR in favor of #1653 🙏

Thank you for the contribution