And while I'm distracted onto the topic of names...

[jducoeur]

Today's project is starting to implement Multiple Choice. (AKA enumerations.) The concept has existed for a long time, but it's a manual PITA to create a multiple-choice Property, and I'm tired of it, so I'm turning it into a proper Type. That's complicated, but so far well in hand.

But as part of it, I've been staring at all these places that are using the Link Type, which is the underlying basis of Multiple Choice. Link is *the* most important Type in Querki -- it's a reference to a specific Thing, basically the equivalent of a "pointer" in most programming languages. (Multiple Choice is implemented as a Link Property to a particular Model, whose Instances are the options to choose from. That's very powerful when you need the power, but like I said, a pain in the tuchus to build one; time for a proper wizard that hides the details of what's going on for the common cases.)

Anyway, I am suddenly realizing that "Link" is also a terrible name. Specifically, while it is *technically* quite accurate, that accuracy is mostly irrelevant: the pointer gets auto-dereferenced in almost all circumstances, so the fact that it *is* a pointer is rarely useful to the end user. Mostly, it's taking brain space for no good purpose -- as far as the user is concerned, it's just a Thing. So I should probably change the name of the Type.

I can't just call it "Thing" -- that's already the base Model for the entire Querki universe, and is quite central -- but I'm tempted to use "Something". That's vague, but that's kind of the point: when you're referring to a value of type Something, it can literally be any non-primitive value in Querki. (Including Properties, Types, People and so on.) In practice, you can restrict the Model that a given Property can point to, and we'll eventually enhance the functions to preserve this typing in the code -- basically implicit generics -- but conceptually, it's just "Something".

The vagueness kinda bothers me, but I don't have a better idea yet, and it seems to relate in an appropriate way to the concept of "Thing" -- a value of type "Something" contains one or more Things. Opinions?

Comments

[goldsquare.livejournal.com]

Magic. "The True Name Of The Thing". :-)

More intelligently, it is really an s-link. Would it help or confuse to call it an sThing?

[mneme]

Proxy?

I have to admit that Something beats Void *.

[jducoeur]

But it *isn't* a Proxy, it's a Reference. And as far as the end user is concerned, the fact that it's a Reference just doesn't matter: you wind up simply thinking about the Thing that it's referring to, not the reference itself, so I'm trying to erase that indirection from the naming...

[mneme]

Can you change what thing is being referred to?

Functionally, a Reference that you can use as if it's the referent is a Proxy; it's a reference, yes, but as long as you don't treat it as such it "looks" like the referent.

Although actually, I think taking a page from C here (ish) is actually a strong plan.

What you have is a Thing (which Thing, well, that can change, but it has to be a Thing, right? Because everything). But it can vary which Thing.

So it's Some Thing. If instead it was a reference to any Person (including subclasses) it would be Some Person.

Ok, maybe not, but...

[jducoeur]

Can you change what thing is being referred to?

Depends on the context. In the context of the "database", yes -- a *property* of this type can be changed. In the context of the QL programming language, no -- the language is pure-functional, and in-flight values are immutable. (To my pleasant surprise, this turned out to be a natural side-effect of making the language as simple and comprehensible as I could come up with.)

Functionally, a Reference that you can use as if it's the referent is a Proxy; it's a reference, yes, but as long as you don't treat it as such it "looks" like the referent.

Fair point. But it goes to the heart of why I want to change in the first place: the fact that it's a proxy isn't relevant to the end user, and I'm specifically trying to de-emphasize that point. As far as they're concerned, they're actually working with the Thing itself; the fact that what is actually being passed along through the program is the Thing's OID is effectively an implementation detail.

[mindways]

Can you not rename Thing to BaseThing, CoreThing, RootThing, or something similar? It seems like on a day-to-day level, most users are apt to be dealing with Links rather more often than dealing with the base Model for the Querki universe. Using the simpler nomenclature (a limited resource) for the more commonly-interacted-with concept seems to make sense.

(It would require *you* to do a good deal of mental rewiring, of course.)

[jducoeur]

Possible, yes -- in practice, it's rarely encountered by end users and is kind of hyper-primitive. I'm wrestling with the idea: it feels incorrect to me to change that, but it's hard to be sure how much of that is the mental rewiring you allude to, as well as a measure of fear of unintended bugs. But you might be correct...

[hudebnik.livejournal.com]

I was leaning sorta the same way. If ordinary users use what's-now-called-Link more often than what's-now-called-Thing, the former should have a more-common word as its name. Perhaps Thing and Object respectively; the latter sounds a bit more technical, and will ring the bells of programmers, as it should.

[alexx-kay.livejournal.com]

"something" is so vague as to be nigh-useless, IMAO.

I note that, although it has a jargon meaning, "pointer" is a perfectly cromulent English word. (quick google...) It appears to be the 992nd most common word, which I think is a good sort of frequency for the job.

[laurion]

"Target", "Source" ? Wrong connotations?

[jducoeur]

Not obviously correct connotations, anyway -- those are sometimes going to be correct names for the *property*, but they don't seem appropriate for the type in general.

And really, they have the same problem as "Link": they emphasize that this is an indirection. That's really what I'm trying to get rid of -- while it's technically true, it isn't useful or interesting.

In a way, it occurs to me, I'm recapitulating the history of programming languages. Once upon a time (with C and the like), the fact that you were talking about a pointer was crucial to how you thought about the value, and so it was upfront: your type would be "House *" to say explicitly that it was a *pointer* to a House. But nowadays, that's almost completely elided -- you just say that your variable is a "House". The fact that it's actually an indirection under the hood has been, intentionally, suppressed.

So what I'm looking for is the term that says "this is a Real Thing" -- something that has its own individual identity in the Space, that has a page you can look at, and so on. mindways may be right that I should just suck it up, rename "Thing" to "UrThing" (which is actually what it's called internally in the code) and name this type "Thing". But I'm still musing...