I don’t want an app about music; I want an app about soundtracking my life.
Sure, being able to pick songs and follow artists is OK and all, and should
probably be a feature of the app I’m imagining, but it’s not the app. It’s the
“manual override” mode in the app, the time in Google Maps where you add towns
you don’t actually want to stop in to Google Maps to trick it into directing
you around a bridge you’d rather not deal with at rush hour. It’s the exception
to my use of the app, not the rule.
The alternatives to go iterators (AKA go range-over-func experiment) are all
worse.
The situation I have is: I have a struct that represents a large collection of
large structs, and I have a few reasonable requirements:
Encapsulation: clients of this package should not be able to mess with the
collection; its members are validated and sorted in some way
Iteration: clients of this package need to be able to make a subset of the
collection, hunt through the collection for a specific item, etc. In
general, clients need to be able to loop over the collection.
Performance: the collection and its members are large, but the application
is time and memory sensitive, so I don’t want to copy large slices
Simplicity to consume: clients of this package should not hate me.
We’ll look at some examples of things I could try to meet these requirements,
and see why all of them fall short in some way without using go iterators.
I know it’s 2024, but I just got a debug build of an iPhone app onto an iPhone.
I thought I’d document the process explicitly because, although this process
has been around forever, there is a lot of incomplete and confusing information
on the web about how to actually get an app on a phone. So now that I’m blessed
with the hindsight of seeing “Hello world” on my own little glowing rectangle,
I thought I’d share how I did it. This is the blog post I wish I’d found before
I started worrying about how to do it.