Folknology wrote:Omitting completely to respond your answer in detail I just read the following from it:
We do need to cover this, else we mis one of the most important advantages
OK convinced will go into detail.
Folknology wrote:The SPI interface is an object, handing in the ports, clocks and clock division as parameters. Internaly they are stored for the XC implementation in the struct spi_master_interface. The constructor would call spi_init
The destructor would call spi_shutdown.
These are what I would classify as module lifecycle functionality, controlled by messages over channels
It is hard for me to understand the difference between a lifecycle and an object lifecycle - too much into the OO world. Since as long as there is somebody I can takl to it is an instanceof something.
But I will try to forget it ;)
Folknology wrote:
spi_out_* would be hidden in member function write(), function overloading would automatically select the right function spi_out_word, spi_out_short, spi_out_byte, spi_out_buffer.
Again I would use channels (and protocols) to output to an SPI module. Protocols would determine frame/width etc.. with the benefit of typing the interface (obviously we have to work around this for now as we lack protocols, but could use structured headers for example).
You are right: If I call a method or send a message over an channel it does not make a difference. It is just sending a bunch of parameters and perhaps getting a response.
The only thing I would not like about the current message over channel idea is the tedious switch/case to respond to different methods. I really like that the compiler does that for me and also does all the neccessary checkings.
Perhaps we can learn from script languages and
duck typing to get a more flexible approach. Since from my point of view strong and irrational hierarchical object models are not really the way to got. There is already too much OO
baklava code out there.
I was really thinking using
BSON as communication protocol over channels can be a good idea. Probably not. But the idea behind it that you get a message and either you understand and respond to it or not. Duck typing
But a BSON like structure can be most easily interpreted as an object - but you can get away with structs & methods.
But encapsulting all methods in channels and message would throw a way a good part of the job of the compiler. It checks for me if the correct parameters are given. On the other hand with duck typing this would throw away the most of the flexibility - that I jsut can try to talk to the module.
Folknology wrote:
I do not know if this would be done for the read function - because then you would need to hand in the result variable as reference not the nicest way. But perhaps the cleanest way in using overloading.
This is important and a place I believe your plan may come unstuck please provide a basic example and I will expand.
By that you can reduce the interface virtuall to two functions: read & write
Or a single/dual channel/s interface (reading and writing is implicit)
See my example above - it is awkward.
Folknology wrote:
To make XC want me forget C++ we need in XC:
Modules with name spaces and private data
protocols to get around this 'encode data in channels' mess
Yup modules with namespaces make stuff more readable and its a nice to have
Protocols are essential longterm so the compiler can check the contract, in the meantime we can use documentation and practice instead (think dynamic language approach)
Agreed, see above.
Folknology wrote:
If you add some kind of contract so that different modules can fulfill the same contract (see my example about ADCs above you got me
This is simpler than the SPI example really as it only inputs data, over a channel. The module does however support config/control via a channel.
This could also be solved by duck typing - It seems I am loosing focus ;)
Folknology wrote:
Are contracts hierarchical? Is a multi input ADC a specialisation of a single input ADC?
It would be trivial for the ADC module to provide an array of input channels as manys as are required for the application configured at start up.
regards
Al
That would be a whole lot of channels - or perhaps it is just an optional field in the message: 'channel' A multi channel ADC would assume '0' if the channel is not given.
I think I want C++ just because there are contracts or services which I can implement or use and this is currently missing in XC.
What I realised only yesterday is important too: in XC is already about inversion of control. This is really good. Everything is controlled by the main function. It instatiates (excuse my wording) the building blocks of the application and configures them So if my LED sink driver uses an SPI protocol it not grabs one of the SPI ports, but asks kindly to provide an SPI configuration as part of it's configuration. This is xtremely important for configurability, flexibility and reuse. Like!