We want to convert a var from ABC to AB. Although ABC meets all the constraints of AB, the additional excess properties sometimes break things and TypeScript will, sometimes, complain about them.
So we could just do this:
declarevarmyVar:ABC;deletemyVar.c;
But that’s not really desirable because, assuming TypeScript even lets you do that, you’re mutating an existing typed object. myVar is still typed as ABC, even though it no longer has a c property.
I used to frequently write code that cloned myVar, deleted the extra property, and then typecast the clone to a new interface. But with the introduction of destructuring and spread operator support in TypeScript 2.1, it’s actually quite simple now:
let{c,...newVar}=myVar
Tada! newVar is created without the c property, and TypeScript recognizes it.
Free college is apparently all the rage on the left these days. For the purposes of discussion, let’s assume we find a way to actually fund free tuition, materials, and room and board at all public colleges in America. But even if that’s the case, free college isn’t something that liberals should be quick to embrace.
For starters, what would free college do to academic freedom? If higher education is a public good, it follows that the content of higher education is a question for the democratic process. But academic freedom is about the freedom to teach and learn about topics that may not be popular. We already see skirmishes over, for instance, whether the government should fund political science or climate change research. If college was 100% publicly funded, we’d probably get more of that, similar to how state legislatures routinely try to change the content of history books and teach creationism in public schools.
Meteor‘s a nifty “reactive” Javascript framework, and I’ve been plunking away on it with the help of the fantastic Discover Meteor book. One thing I don’t quite agree with the book, however, is their Pagination Chapter (paywall, sorry) doesn’t actually implement traditional pagination so much as a variation on infinite pagination. That is, rather than show posts 1-10, then 11-20, their example shows 1-10, then 1-20, and so on.
This is potentially less-than-ideal for a couple of reasons. First, it forces the client to keep a growing number of posts in memory. 10-20 posts probably isn’t a big deal, depending on your app, but if you’re displaying hundreds of photographs (or animated GIFs), this could get pretty annoying. Granted, you can minimize the impact by only loading elements that are visible on screen, but it’s a headache that you don’t have to deal with traditional pagination.
The other potential issue is that, because Meteor is a real-time framework, the server needs to constantly monitor changes to the database and pass along those changes to the client. As the number of documents inside a database query grow, the number of updates being passed back increases as well. I haven’t been using Meteor long enough to know how much of an impact this makes in practice, but updating off-screen data is, at least, a sub-optimal use of bandwidth.
