Thoughts on a live coding API

#1

I’ve been thinking about various shorthand notations to make experimenting with the JavaScript Console more intuitive.

As an example, consider the “longhand” version of rotating an avatar’s right arm:

var deg15y = Quat.fromVec3Degrees( { x: 0, y: 15, z: 0 } );
var q = MyAvatar.getJointRotation("RightArm");
MyAvatar.setJointData("RightArm", Quat.multiply( q, deg15y ) );

The “shorthand” version would just be:

> avatar.right.arm.Y += 15

Since the command prompt remembers your recent commands, to “undo” this kind of rotation you could simply hit the up-arrow, change 15 to -15 and hit enter again.

A few more hypothetical examples:

// align left and right Y rotations (accounting for L-R symmetry)
avatar.left.arm.Y = -avatar.right.arm.Y

// advance avatar along the X axis:
avatar.position.x += 0.5

// make the nearest FBX model twice as big:
all.querySelector("Model[modelURL*='fbx']").scale *= 2

// make all nearby Sphere's blue:
all.querySelectorAll("Sphere").forEach(function(o) { o.color = [0,0,1] });

// teleport to the nearest "fireplace" entity:
avatar.position = all.querySelector(/fireplace/i).position;

These abstractions might seem a little strange (compared to the existing API), but everything above is really just syntatic sugar – and requires only pure JavaScript to implement as a wrapper around the existing API (no C++ changes needed!).

Thoughts? And are there other objects that would be interesting to work with using shorthand? Maybe creating certain kinds of placeholder entities in bulk?

#2

I like some of the ideas, however,
the joints are assigned to JS Object JointRotation.jointName. Having it avatar.right.arm wouldnt take account all the other bones, since there can be more bones than the standard skeleton defined in the docs, see my standardization proposall) . Instead the short hand value should be avatar.bones.rightArm…

Although I think it would still be good to have the naming conventions, so static instances should still all be captalized: (so Avatar, All, etc)

#3

@ humbletim I think your examples of using shorthand notations would encourage many to experiment with HiFi javascript. Amateurs ie. those working on a need to know basis, would after reading the ‘longhand’ code, probably be deterred by the complexity of many terms.with the likelihood that changing any values would be time consuming because of uncertain or unpredictable results.

Your ‘shorthand’ notation would i think encourage experimentation by users - who mostly just want stuff to happen without looking under the hood, While an explanation of the code steps, may not be fully explained in the shorthand version, in usability terms it would be very helpful to encourage learning and if people want to go deeper they can use the original API documentation.
haha Who was it said ‘quaternions were never meant to be read by a human, so get over it’ ?

#4

@Menithal - Ahh, cool! I just looked at the standardization proposal and joints do sound like something important to reach a consensus around. What I was thinking with avatar.right.arm was like ‘folder/folder/file’ or IP address octets – leveraging the existing structure to enable simplified navigation between bone “waypoints” (ie: holding a reference path to any bone, just drop the last segment and now you are holding its parent).

Hmm, in early prototypes “all” is just implemented as a proximity search, but maybe it should actually refer to the entire Domain? (and a different word used for nearby objects?)

@ritzo – I don’t know who said that, but they probably also said ‘Quaternions are a dish best served cold!’ :wink: But yeah a big part of the idea here is to hide extraneous story problem information while promoting relevant details in context. I like the documentation hook. With Python’s console prompt, when you type a bare function name it’ll show you the inline documentation for it – maybe something like that could be done here.