00:13 <jfhbrook> oh geez ok that's hilarious

00:13 <jfhbrook> I came at this like, oh, I want a constructor and some methods, this sounds like a good use case for a class

00:13 <jfhbrook> but it turns out what I *actually* want is an object decorator

00:13 <jfhbrook> ie, I've been hacking on this project for a *while* and I still haven't had a need for classes

00:14 <jfhbrook> and not like in an avoiding them way, more in a bad fit way

00:14 <jfhbrook> what a funny language

00:14 <jfhbrook> in python this woulda 100% be an ABC

00:16 <ljharb> funny language aka "multiparadigm"

00:16 <ljharb> :-p

00:16 <ljharb> greatest {strength,weakness}

00:18 <jfhbrook> python is also arguably multi-paradigm

00:19 <jfhbrook> though a number of its design decisions make classes preferred over closures and require special syntax for certain actions

00:20 <jfhbrook> for instance, python by default defines variables in the current scope as soon as you try to assign, even if there's a variable in the outer scope w/ that name - it shadows it. that means you need special keywords (nonlocal and/or global) to set variables via closure

00:21 <jfhbrook> on the other hand, python's classes can manage that state just fine, and in fact can even be accessed via the closure! ie, state_dict['count'] += 1 is totally fine

00:22 <jfhbrook> python classes will also copy class properties onto the instance, which gives a cheap way of setting default values on the instance sans constructor

00:24 <jfhbrook> and because all classes are defined explicitly, you can almost always do a meaningful isinstance check

00:25 <jfhbrook> oh, and python lambdas are single statement only so you need special syntax for decorators

00:26 <jfhbrook> so even though python has map and reduce and comprehensions and first class functions (and callables!!), it's still often idiomatic/easiest to use a class

00:28 <jfhbrook> meanwhile, javascript has cheap object literals, much better support for iterating over keys (attributes in python), multi-line anonymous in-line functions and so on, means more duck typing, mixins, instance modification and just way fewer classes

00:28 <ec> yeah, I never do OO … anything, anymore, unless the API’s for someone else

00:29 <ec> really the only single thing OO’s got going for it, is documentation

00:29 <jfhbrook> well with python in particular it's really hard to write without doing boring ol' oop

00:29 <jfhbrook> like it's "multi-paradigm" but it truly shines in oop contexts

00:30 <jfhbrook> and like, javascript still has objects! and you don't need to write traditionally object-oriented code on top of them but I'd argue that it's still got quite a bit of oop in there

00:31 <jfhbrook> in some ways I think of javascript as being /more/ object-oriented than python because javascript is objects all the way down, meanwhile, python is class-based - just my hot take is all

04:13 <jfhbrook> current version: https://gist.github.com/jfhbrook/51801e5a085283b0e2807cd0bb366292

04:14 <jfhbrook> looking better! I think I need to move the setTimeout into the hook and I need a linter that's more opinionated about the amount of space between things

04:14 <jfhbrook> I think the pattern of creating a closure around a component is a little funky but only a little

04:17 <jfhbrook> also this one creates the logger and then doesn't use it - logging inside the component is a little dangerous and not really needed here

04:18 <jfhbrook> yeah, like, useTimer, no state of its own

04:20 <jfhbrook> might get rid of processParams too, it's kinda needless indirection

04:20 <jfhbrook> just gotta bite the bullet with that one!

22:08 <ec> fuckme, Travis-CI's macOS machines are so slow

22:38 <ec> if anybody wants a window into my current, personal hell: https://stackoverflow.com/questions/58309538/what-does-upload-pack-not-our-ref-mean-when-fetching-git-refs-via-tags