riki/treehouse
riki/treehouse
1
Fork 0
Code Issues 33 Activity

update issues

Browse source
This commit is contained in:
りき萌 2024-07-22 20:34:42 +02:00
parent 04a346d851
commit 2a68cfbf63
44 changed files with 1201 additions and 318 deletions
Download patch file Download diff file Expand all files Collapse all files

25
content/programming/opinions.tree
View file

@ -21,7 +21,7 @@
- you say `info` sounds wrong for debug info? well,
% id = "01HBTSXTTATA4GW13QBC8YMWP1"
- guess what, it's debug ***info***
- guess what, it's debug _*info*_
% id = "01HBTSXTTANNMHXDGG1M4W70XN"
- the very concept of logs is to dump a load of (debug) info for later analysis,
@ -172,10 +172,10 @@
- I'd rather have the program crash and burn at the point a `NaN` is produced rather than have to sift through all the math to find that one division by zero I didn't account for
% id = "01HPEMVAH9XG3RK62RFXD29RWV"
- this does influence performance negatively, but it saves *so much* debugging pain and finding out which non deterministic scenario causes a NaN to propagate through the system
- this does influence performance negatively, but it saves _so much_ debugging pain and finding out which non deterministic scenario causes a NaN to propagate through the system
% id = "01HPEMVAH9CKAEQBMC8S6MR0GQ"
- worst case scenario you pull a Rust and disable those checks on release mode. that *does* work, but I don't like the idea of disabling numeric safety checks on release mode either.
- worst case scenario you pull a Rust and disable those checks on release mode. that _does_ work, but I don't like the idea of disabling numeric safety checks on release mode either.
% id = "01HPEQ01JRMM17Y30BP7ZFKZRJ"
+ :page: operator overloading is good, but getters and setters are not
@ -184,10 +184,10 @@
- this one stems from an argument I had today, so I'll write my thoughts for future generations' enjoyment here
% id = "01HPEQ01JR4YWC9Q6VYS82J0E3"
- I'll start by prefacing that I think operator overloading is good [*iff*][def:word/iff] it's implemented in a way that a single operator has only one, well-defined meaning
- I'll start by prefacing that I think operator overloading is good [_iff_][def:word/iff] it's implemented in a way that a single operator has only one, well-defined meaning
% id = "01HPEQ01JRBB8Z3P0KFJSR0SJN"
- this means `+` really means *addition* and nothing else.
- this means `+` really means _addition_ and nothing else.
% id = "01HPEQ01JRJJBP9C701B36ZR4N"
- this is practically impossible to enforce at a language level - what prevents the standard library authors from overloading `+` to mean string concatenation after all?
@ -196,13 +196,14 @@
- however we can at least do our best by writing good defaults and coding standards that gently suggest what to do and what not to do
% id = "01HPEQ01JR4ZC0M68818EDVDBF"
- for example, allow users to define their own arbitrary operators that are explicitly *not* addition, to incentivize inventing new syntax for these things
- for example, allow users to define their own arbitrary operators that are explicitly _not_ addition, to incentivize inventing new syntax for these things
% id = "01HPEQ01JRTWHH6PVNTFBDXPVT"
- the way I'd like to do it in [my dream language][def:rokugo/repo] is by a few means
% id = "01HPEQ01JRAAK5MQCZ7CFZ75FA"
- `(+)` is defined to be a polymorphic operator which calls into a module implementing the `AddSub` interface, which means you have to implement both addition *and* subtraction for `(+)` to work on your type
- `(+)` is defined to be a polymorphic operator which calls into a module implementing the `AddSub` interface, which means you have to implement both addition _and_ subtraction for `(+)` to work on your type
```rokugo
let AddSub = interface {
type T
@ -216,7 +217,7 @@
```
% id = "01HPEQ01JR71RV53NNSFFDV6XN"
- note how this operator *does not* have any effects declared on it - this means addition and subtraction must not have any side effects such as I/O
- note how this operator _does not_ have any effects declared on it - this means addition and subtraction must not have any side effects such as I/O
% id = "01HPEQ01JRJR3ZAY24BP8TF5HH"
+ the `(add AND subtract)` rule enforces types like strings to take a different operator, because `(-)` does not have a well-defined meaning on strings
@ -234,7 +235,7 @@
- so now getters and setters: what's so bad about them?
% id = "01HPEQ01JRQPZJEDDXV4BJN1GP"
- the problem is that given the rule above - *one operator means one thing* - getters and setters completely destroy your assumptions about what `=` might do
- the problem is that given the rule above - _one operator means one thing_ - getters and setters completely destroy your assumptions about what `=` might do
% id = "01HPEQ01JR0E8C0VJZ1D9TJRAG"
- what's that? you didn't expect `camera.angle_z = 420` to throw because 420 is out of the `[-π/2, π/2]` range? oops!
@ -250,13 +251,16 @@
% id = "01HPEQ01JRQFSFVPQA41MFZ91T"
- this is less of a problem in languages that feature automatic generation of getters and setters - such as Kotlin
```kotlin
var someVariable: String
get
private set
// no infinite recursion to be seen here!
```
but it's still an issue in eg. JavaScript, where one mistake can send your call stack down the spiral:
but it's still an issue in e.g. JavaScript, where one mistake can send your call stack down the spiral:
```javascript
class Example {
#someVariable = "";
@ -265,6 +269,7 @@
set someVariable(value) { this.someVariable = value; } // typo again!!!!!!!!!! dammit!
}
```
and the error is not caught until runtime.
% id = "01HPEQ01JRMMS1B400DP6DV5M9"