Native marker for solidified code

[s-hadinger]

I have made some improvements in solidify that I need to upload...

Now solidify works with modules, classes, lists, maps... But when it comes to classes or modules with native functions, there is no way to mark them as native.

I would like to have a Berry skeleton, solidify it and then add native functions. I see two alternatives to do that.

1/ add native keywork

class myclass
    native f
    def g() end
end

Pros: allow any name
Cons: adds a new reserved keyword

2/ use a naming convention, like any name starting with ntv_ or native_

class myclass
    static native_f       # will be recongnized by solidify module that will add a native function stub instead
    def g() end
end

Pros: no change in parser
Cons: naming by convention... Some people don't like it

Afterthoughts I prefer option 2.

[skiars]

Do you mean that these symbols will generate a placeholder and then implement C native functions by myself?

[s-hadinger]

Yes, but in this case the native function already exists. I will provide an example.

[Sebight]

Hello, sorry for this necro, however I am wondering whether something like this was ever implemented.

I am facing an issue with this code:

class SpectodaInterface
    def init()
        print('Initializing SpectodaInterface')
    end

    def emit(eventIdentifier, value)
        print("[BE]: Called with eventIdentifier: "+ eventIdentifier + " and value: " + value)
        native_emit(eventIdentifier, value)
    end
end

import solidify
solidify.dump(SpectodaInterface)

This will always call this error: syntax_error: solidify.be:8: 'native_emit' undeclared (first use in this function), I even tried doing something like a forward definition:

class SpectodaInterface
    def init()
        print('Initializing SpectodaInterface')
    end

    def native_emit()
        # To be implemented by the native side
    end

    def emit(eventIdentifier, value)
        print("[BE]: Called with eventIdentifier: "+ eventIdentifier + " and value: " + value)
        native_emit(eventIdentifier, value)
    end
end

import solidify
solidify.dump(SpectodaInterface)

But still no success.

Note: The native_emit function is register using this be_regfunc(vm, "native_emit", SpectodaInterface::native_emit);.

Thank you

[s-hadinger]

It's hard to tell because I don't know what native_emit actually does.

You initially defined native_emit as a global function (not a member class), that's why I have indicated to declare it as static_func(s_native_emit) which means that it does not take self as a first parameter. Now if you need self, declare it as func(s_native_emit) instead

[Sebight]

Yes, I am sorry. I'm still quite confused about what I want to do, as I'm still learning about how Berry works.

My final usecase is this, separated in three layers:

• Native C++ classes that I want to "inject" into Berry as globals. These will be directly linked to C++ and are classes such as spectoda, gpio, ...
• Berry drivers that will get solidified and will interact with these native globals, such as BerryExampleDriver
• End-user Berry code that will have a few life-cycle functions called directly from C++ (start, update, ...) and will be used to interact with the Berry drivers => BerryExampleDriver.calculateAThing()

I have a few questions though:

• Should I keep the native classes static to represent some sort of a singleton? I suppose that could work.
• Those solidified Berry drivers should, however, be normal classes that can get instantiated. Or do you think otherwise?

I'm certain you have much more experience in terms of building architecture around Berry, so would you mind sharing your thoughts? Thanks a lot!

[s-hadinger]

Sounds awesome.

There is no definite pattern for singletons, this is what I do:

• Tasmota_ntv is a native class with C/C++ code. I have a mix of static (class methods) and regular methods
• Tasmota is a Berry sub-class of Tasmota_ntv and is solidified
• tasmota is a singleton instance of this class that is created in a startup script

This pattern is straightforward. I haven't found any simpler or better way until now.

[Sebight]

Looks sweet! However, why do you create the Berry layer for your Tasmota class? Couldn't you just make Tasmota_ntv as "tasmota"

In something like this:

class be_class_Tasmota_ntv (scope: global, name: tasmota) 

Because for me, my tasmota class will be just directly calling C++ functions, no additional Berry implementation.

[s-hadinger]

Because I need to keep some data around. For example I keep a list of custom "drivers" in a list as an instance variable of the singleton; this avoids polluting the global namespace.

Edit: I should add that a solidified class has its static variables read-only