You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I look at booklet. Very impressive work. Congrats!
But I found some places which I assumed to be done differently according to my initial design ideas. So two things.
Instantiating pins in examples.
I see it in many places something like in Blinker code:
initialize
led :=PotClockGPIOPinid:4number:7.
led board:RpiBoard3B current; beDigitalOutput
Board model itself provide all existing and configured pins. So it is not correct to create pin instances again and connect them to the board. You can simply ask the board to give you a pin by id:
led :=RpiBoard3B current pinWithId:4.
led beDigitalOutput
This way users don't need to think about class of pin or number or whatever except id of pin where they are actually plug real physical stuff.
So the board class takes care about all pin details. It is its purpose to provide this configuration.
Usage of global "PotBoard current" and device model
Continuing the blinker example. Globals in initialization is definitely a code smell. And it would be good to avoid it even as simplification of examples.
Particularly hardcoding global board does not allow to use this code with different board instances. For example there is dummy support for boards to test things out of real equipment:
RpiBoard3B dummy
And it is impossible to use blinker with dummy board without modifying global. It is impossible to have two blinkers in same image, to have unit tests.
So alternative to global is having board variable in your classes. And here we are going to device model. Blinker, WeatherStation, Flowing, they all can be modelled as board devices. Simply subclass them from PotDevice and you will get ready "infrastructure" for implementing their logic: #board instance, methods to start/stop main logic, they will be accessible and controlled from board inspector (devices tab).
So blinker device needs to implement abstract method #connect:
connect
led := board pinWithId:4.
led beDigitalOutput
Then to activate blinker you just need to add it into the board:
From device tab you will be able disconnect/delete blinker. And you can do shutdown logic in #disconnect method (like terminating blinking process).
In addition you can show state of device peripherals in device tab. It can be either pins or other devices which is used by given device logic. In case of blinker it would be simple led:
Blinker>>peripherals
^{led}
The text was updated successfully, but these errors were encountered:
Hi denis
Thanks for the feedback we will do a massive sets of changes.
And this is great if you can have a look at them.
We want to provide abstraction and encapsulate as much as possible (forkNamed: and others).
Denis what is the difference between a peripherals and a device?
I started to read the PotDevice class and hierarchy.
And do you have a process that is scheduled?
I see that in WaterAlarm the connect logic the following one.
Hi @oliveiraallex .
I look at booklet. Very impressive work. Congrats!
But I found some places which I assumed to be done differently according to my initial design ideas. So two things.
I see it in many places something like in Blinker code:
Board model itself provide all existing and configured pins. So it is not correct to create pin instances again and connect them to the board. You can simply ask the board to give you a pin by id:
This way users don't need to think about class of pin or number or whatever except id of pin where they are actually plug real physical stuff.
So the board class takes care about all pin details. It is its purpose to provide this configuration.
Continuing the blinker example. Globals in initialization is definitely a code smell. And it would be good to avoid it even as simplification of examples.
Particularly hardcoding global board does not allow to use this code with different board instances. For example there is dummy support for boards to test things out of real equipment:
RpiBoard3B dummy
And it is impossible to use blinker with dummy board without modifying global. It is impossible to have two blinkers in same image, to have unit tests.
So alternative to global is having board variable in your classes. And here we are going to device model. Blinker, WeatherStation, Flowing, they all can be modelled as board devices. Simply subclass them from PotDevice and you will get ready "infrastructure" for implementing their logic: #board instance, methods to start/stop main logic, they will be accessible and controlled from board inspector (devices tab).
So blinker device needs to implement abstract method #connect:
Then to activate blinker you just need to add it into the board:
Which can be done using the global in playground:
From device tab you will be able disconnect/delete blinker. And you can do shutdown logic in #disconnect method (like terminating blinking process).
In addition you can show state of device peripherals in device tab. It can be either pins or other devices which is used by given device logic. In case of blinker it would be simple led:
The text was updated successfully, but these errors were encountered: