and putting structure instances into an array so that you can refer to them via indexes of the array entries (as the only escape from being maimed by the borrow checker) is normal?
you have a point. The usual approach was to choose a subset of C++ features, so it becomes appropriate for a given project.
But yes, the language is huge - as it tries to suite everyone but no one in particular (which is insane)
Go has good (enough) built-in arrays and maps. But if you want a tree, without generics, you're really limited. With generics, you can get a nice containerized type, but you don't get the nicer syntax that the builtins have.
It's not just types, either. Look at the signature for the built-in sort, which is amazingly cumbersome to use. A generic wrapper around it hides all the ugly.
Halted was an electronics surplus store. A really good one. They had old tubes, old ICs, stuff left over from Atari. They had aisles of capacitors, some with date codes in the mid '80s, and newer surface mount stuff. They had a whole wall of 1/4 W resistors at two cents a piece. They had all kinds of random parts for keeping old electronics running, and making new stuff. And they had a receipt for an oscilloscope they sold in the '60s to some kid in Palo Alto named Steve Jobs.
Unfortunately, the owner retired and sold it off for parts.
Seems like it should work for arbitrary byte strings (any charset, any encoding)but obviously the performance characteristics will differ because of non-uniform distribution. But that happens even in ASCII.
that sounds right. and yes, very good stuff! i remember thinking at the time "hah. this is built with real computer science!". and well, at the time, it was the only thing that worked for large mail spools.
i also think it was the first support for sasl(?) encryption upgrades for legacy text/tcp mail protocols
also, fun sidebar: indices vs. indexes, both are apparently valid english... but it seems computer people have adopted the latter almost exclusively. never noticed it before...
SASL came out as a generalization of the IMAP AUTHENTICATE mechanism. CMU wanted Kerberos to work and it had been done as something of a one-off in telnet, and initially in IMAP. There were a couple companion protocols proposed for IMAP (stuff like contacts) that the same group was working on, and they wanted to leverage the same mechanism. From there, might as well do the same thing for POP and SMTP, etc. So they started working on a library (which Cyrus IMAP didn’t use for at least a while, sorry my fault).
Kind of funny that SASL is the most durable piece of the effort.
(I doubt this is entirely accurate. I wasn’t there for a lot of it.)
I overlapped at LinkedIn at the same time as the author. While there, I wrote my first (and to date only) FactoryFactory.
LinkedIn replaced its uses of Spring with a thing called Offspring. Offspring explicitly disavowed being a dependency injection framework, but it did a similar job for us. I rather liked it. Notably, you just wrote Java with it. Invariably, in Offspring, you'd have to write a FooFactory to construct your Foo object to inject it into some (other class. By convention, all of the factories ended in Factory.
Well, I had a use case for a runtime class that needed to make a per-request factory to make little objects. So to make my Bars, I needed a BarFactory; and to construct the BarFactory, I needed an Offspring factory, thus BarFactoryFactory. There it was. I felt a little weird after that.
I suspect the EventFactoryFactoryFactory code here was such an Offspring factory being used for dependency injection, but I can't explain why it produced a FactoryFactory.
> LinkedIn replaced its uses of Spring with a thing called Offspring.
I think dependency injection itself is reasonable, but I increasingly wonder why you need a framework for it at all.
Yeah, for certain extremely complex scenarios, such as dynamically loaded plugins which are only known at runtime, you'd need some "host" code which manages the plugins - though even in that case, it will probably be helpful if that management code is part of your application's codebase, so you can easily debug it.
However, that's already the big exception. I'd claim that in the vast, vast majority of projects, DI is only used during development - and at runtime, there is exactly one way how the object graph is supposed to be assembled. So if that's the case, why not just make a big "application" class in your codebase and instantiate the objects/assemble the graph yourself? What exactly do you need a framework for?
Another exception are callback situations, most prominently web endpoints. A framework can be a big help here to get the headers right, manage auth, caching, CORS etc through filter chains, avoid a good part of typecasting, redundant declarations, etc.
But even there, Java now introduced lambdas and records which makes working with callbacks and "dumb structs" far easier. So the future of "web apps" here might as well be some library which lets you register web endpoints with lambdas - instead some overarching framework which expects that you structure your whole codebase around the fact that your app will serve HTTP on port 8080.
DI at LinkedIn was used for development, for unit test isolation, and to reduce tight coupling.
One big problem with a giant "Application" class is that it means all of the dependencies are laid out there, and their dependencies, and their dependencies, all named and instantiated. But some dependencies are in libraries, and basic detail encapsulation means ... a factory.
Offspring wasn't much of a framework, more of a set of conventions and utilities for building that stuff in plain Java code (with key annotations). In particular, I think the Offspring setup wasn't opinionated about the framework of the rest of the application, although other parts of LinkedIn were (and presumably still are).
> One big problem with a giant "Application" class is that it means all of the dependencies are laid out there, and their dependencies, and their dependencies, all named and instantiated. But some dependencies are in libraries, and basic detail encapsulation means ... a factory.
Indeed they are - and I strongly believe that is a good thing. Because at which other place are all your dependencies laid out and instantiated? In your deployed application code at runtime.
So to understand your application in its entirety (and not just individual components), knowing the whole object graph is essential. And the easiest way to know it is if it's already written down somewhere.
This doesn't have to keep you from enforcing loose coupling and encapsulation, at least for certain definitions of those:
If you want to keep the components encapsulated - i.e. ensure that FooService works with any implementation of BarService - you can still do that: Just ensure the individual components only refer to each other through interfaces and forbid direct dependencies between them. Then in the end, the application class should be the only location in the entire codebase where multiple concrete components interact in the same class (excluding tests).
You can even enforce this by putting each components in a separate artefact and only allowing dependencies to an "API" artefact that is distinct from the implementation.
However, if you understand loose coupling such that no part of the application should know about the other, and the entire application assembles its component through some magical algorithm, I'd call into question why this is even a desirable property: You still have an object graph, you just go out of your way to hide it. And it's still very important that the object graph must be assembled in some very specific way, which is why the algorithm must be coaxed into doing the right thing with qualifyer annotations or magic priority numbers.
I don't have any inside knowledge, but I'd guess an EventFactory is tied to a specific Event type, so the FactoryFactory is about producing Factories for any such type? I'd never have guessed the third though.
An hourly rate was tried and it was a pain in the ass for staff and now it’s gone. (Source: I am an irregular volunteer technician, and have been going there as a customer for 15 years.)
