stage 0: add arrays + interfaces and lists lessons - #188
Conversation
Co-authored-by: 0verkil <112268976+0verkil@users.noreply.github.com>
Removed duplicate lockfile key, reverted package upgrades
|
🌐 Preview URL: https://pr-188.frcsoftware.pages.dev |
ff6f4ce to
997d1b7
Compare
997d1b7 to
f8d173f
Compare
|
|
||
| ``` | ||
|
|
||
| Here, `isTooClose` is defined to take a `DistanceSensor`, so it doesn't matter whether we pass in an `UltrasonicSensor` or a `LidarSensor`. |
There was a problem hiding this comment.
I think putting the definition of isTooClose would help here.
| ## A Generic Method | ||
|
|
||
| Interfaces let one piece of code work with several related types. | ||
| **Generics** go a step further, letting a method work with _any_ type. |
There was a problem hiding this comment.
Generics aren't just for methods, so I think it might be better to broaden the scope of this slightly. Particularly, I would start with describing what Object is, then trying (and failing) to implement a Pair class with it, then showing how generics allow you to successfully implement said Pair<A, B> class.
That also allows for a good segue into why Integer and Double exist.
|
|
||
| ## Packages and Imports | ||
|
|
||
| So far, every class we've written has had no package, which is why our classes could use each other with no `import` statements at all. |
There was a problem hiding this comment.
I would personally start by describing the relationship of package = directory = folder, while mentioning that package is the java name for a folder.
Also mention that all package definitions are relative to the src/main/java folder.
|
|
||
| ```java {usage}#importList | ||
|
|
||
| ``` |
There was a problem hiding this comment.
Using the file directory view that you implemented in Stage 1A would be great here. Each file could be denoted by Something.java lives in package something.here to build a better intuition as to how packages work
| Classes built into the Java Development Kit (JDK), classes from external libraries like WPILib, | ||
| and classes in our projects live in **packages**, named groups of classes. | ||
| A package's name exactly matches the directory it lives in. | ||
| For example, all of the classes in the `java.util` package live in the `java/util` directory of the JDK library. |
There was a problem hiding this comment.
I think this part would be better explained as like copy-pasting code. Something like,
importing a class is essentially copy-pasting someone else's code
for your own use. To do so, you need to know the folder(s) that the code lives in,
and the name of the file that holds the code.
If you wanted use a class named `Point`, located in `Point.java`,
you would add `import myFolder.subFolder.Point` to the top of your java file.
Files within the same package, or folder, can access each others' contents freely (without imports).
If you move that file to another folder (even a subfolder), though, you have to update your imports accordingly.
| default: stage0/snippets/src/Arrays.java | ||
| --- | ||
|
|
||
| In an [earlier lesson](/learning-course/stage0/classes-methods/), we defined a `Point` class to represent a location on the field. |
There was a problem hiding this comment.
| In an [earlier lesson](/learning-course/stage0/classes-methods/), we defined a `Point` class to represent a location on the field. | |
| In the [previous lesson](/learning-course/stage0/classes-methods/), we defined a `Point` class to represent a location on the field. |
|
|
||
| If the rest of your robot code is written to only work with one specific sensor class, swapping hardware means rewriting everything that used it. | ||
| An **interface** solves this by describing what a sensor can do, without saying which specific sensor it is: | ||
|
|
There was a problem hiding this comment.
@Override is introduced but it's not mentioned. I think a short explanation of what Override is would be helpful. especially since it's in robot code
Description
this is two pages so it's more digestible 👍
Meta
Merge checklist: