Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request some changes in code examples #12

Open
dionisiydk opened this issue Mar 21, 2019 · 3 comments
Open

Request some changes in code examples #12

dionisiydk opened this issue Mar 21, 2019 · 3 comments

Comments

@dionisiydk
Copy link
Contributor

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.

  1. Instantiating pins in examples.

I see it in many places something like in Blinker code:

initialize
  led := PotClockGPIOPin id: 4 number: 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.

  1. 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:

blinker := board installDevice: Blinker new.

Which can be done using the global in playground:

blinker := RpiBoard3B current installDevice: Blinker new.
blinker timesRepeat: 10 waitForSeconds: 1.

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}
@oliveiraallex
Copy link
Contributor

Hi @dionisiydk .

Thanks!
I get the point, thanks for the help.
I'm rewriting the code and doing new tests to update the booklet.

@Ducasse
Copy link
Member

Ducasse commented Nov 15, 2019

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).

Stef

@Ducasse
Copy link
Member

Ducasse commented Nov 15, 2019

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.

connect

trackingProcess := [ self waterTrackingLoop ]
	forkAt: Processor userBackgroundPriority named: self printString, ': water tracking'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants