search

clarity-lang / reference

The Clarity Reference
146 stars 34 forks source link

Rename print to event #40

Open lgalabru opened 3 years ago

lgalabru commented 3 years ago

Events are a really convenient mechanism implemented via (print). As a smart contract developer, when discovering the documentation, it's not obvious that event sourcing designs can be built using (print) (could even feel a bit hacky), I think that renaming to (event) or similar would make it more obvious.

friedger commented 3 years ago

Maybe emit as a verb

njordhov commented 3 years ago

Maybe emit as a verb

Another candidate is dispatch, but emit is a good term, particularly when there are no clear destination for the event.

psq commented 3 years ago

whatever name you pick (bicycle is fine for me), the only thing I've been using print for is to get the value output in the node log for debugging, so please keep this functionality. The events have not proven useful just yet, especially as the ordering is not kept in the explorer.

Note: the bicycle reference is a joke... as long as it is not a word already overused in the log file.

njordhov commented 3 years ago

the only thing I've been using print for is to get the value output in the node log for debugging

What about a step up from caveman debugging, with a ~bicycle~ spy construct that provides a more detailed log: https://github.com/blockstack/stacks-blockchain/issues/1390

psq commented 3 years ago

I would think we can do even better, especially with an interpreted language, where you can write tooling to show you all possible values as you move forward/backward so you don't need to instrument the code to figure out why something happened, or did not happen. It is more a UI issue. You have some of that in clarity.tools. So in the meantime, I'm happy with the caveman approach

njordhov commented 3 years ago

I would think we can do even better, especially with an interpreted language, where you can write tooling to show you all possible values as you move forward/backward so you don't need to instrument the code to figure out why something happened, or did not happen. It is more a UI issue. You have some of that in clarity.tools. So in the meantime, I'm happy with the caveman approach

Having a spy construct in the language is just a means of giving the caveman programmer access to some of those more sophisticated debugging features. Enclosing an expression in a (spy...) form could be functionally equivalent to selecting the same expression in Clarity.Tools to activate call reporting. It's just a different UI.

hstove commented 3 years ago

This is a great idea. Typed events might be the only Solidity feature that I wish we had. It really makes it quite easy for off-chain indexers to be built. For example, The Graph is built solely around events.

I understand that you can put anything in a print, like a tuple. However, for indexing, you really want typed+named events. If we had typed, named events, then the API could easily serve something like /:contract/events/:event-name. Right now if you want to use print events to index, its pretty hacky. A good example is our solution for "stx transfer with memo from a contract".