Draggable line

[tfadali]

• added missing styles
• added line object
• new draggable line demo

[GregStanton]

Let's come to a tentative consensus on the 'setIsDraggable' name before we merge this, since it affects the interface. Here are some issues to consider.

Comparison to our naming scheme for event listeners: The name is consistent with the naming scheme for event listener setters, such as setObjectIsHovered(). However, "setIsDraggable" sets a Boolean, whereas "setObjectIsHovered" sets a listener that returns a Boolean. This may be okay, since there are two cues that these setters accept different kinds of input. The biggest cue is the "-able" and "-ed" endings. The other cue is that the passive "isHovered" is paired with "Object" (the thing being hovered). So, the "setIsDraggable" name seems okay from this perspective.

Comparison to p5
Some cases where p5 uses "set" are as follows:

• setAttributes() is a general setter for WebGL that can be called like setAttributes(key, value) or setAttributes(obj)
• setMoveThreshold()
• setShakeThreshold()
• set() for setting pixels or writing a whole image to the display window
• setCamera()
• .set() for p5 vectors and for p5.Camera objects (p5.Camera objects also have .setPosition())

Some cases where p5 uses "is" in a function name: isLooping() and keyIsDown(). Neither is a setter. Both return Booleans, as we'd expect based on the usual convention.

Since the use of "setIsDraggable" seems consistent with usage in p5, and the use of "isDraggable" as a setter seems inconsistent with p5, the name "setIsDraggable" seems preferable. From this perspective, the current name seems good.

Comparison with the combined getter/setter approach of Konva.js: In this approach, methods like .stroke() do two things: they set the relevant property based on the arguments that are supplied, and they also return the value of the property. So, for example, calling .stroke() without arguments just gets the object's current stroke. In the same way, Konva.js has a .draggable() method that acts as a getter and setter for a Boolean "draggable" flag. However, "isDraggable" makes it more clear that we're dealing with a Boolean (due to the naming convention for Booleans), and .isDraggable() probably shouldn't be used as a setter, to avoid conflict with p5. Again, "setIsDraggable" seems best.

Tentative conclusion: The current name .setIsDraggable() seems to work best. For other functions like .stroke(), we can have a separate discussion to break down the pros and cons of combined get/set functionality. As with many things related to getters and setters, there's debate about whether combined getters/setters are generally helpful or unhelpful. Some pros and cons are discussed here:

• What are the benefits of combined getter and setter methods?
• Independent getter/setter methods, or combined?

[tfadali]

I think what's missing from this analysis is that setIsDrabble, to me, suggests that there is a boolean inside that we are setting. Other developers familiar with common naming conventions will also think that. It's true that you can look at the signature or docs and see that it's a callback, but that's elevating the importance of documentation, relative to making the API intuitive.

[tfadali]

Personally, I didn't pick up on the cues, I don't think. The naming convention is too ingrained for me.

[tfadali]

I don't really see the "-ed" or "-abble" as cues the way you do, and at least in the p5 editor, there isn't going to be any autocomplete suggestion that it takes a callback.

[GregStanton]

In the design I have in mind, the default .mouseDragged() handler would work, so it wouldn't be necessary to set it in the sketch code. It could be customized, but for a sketch like this, it wouldn't be necessary. So, lines 18 through 25 involving mouseDragged() and mouseDropped() wouldn't be needed.

Were you planning to take out these lines once you implement more of the design? If not, I could explain the approach I'm thinking of. It's important that we make the basic interactions work as easily as possible. Of course, I'm not sure yet if the idea I'm thinking of will work quite as I hope!

Naming note: mouseDropped() is a placeholder name unless we can't find something better. Until now, it hasn't been a priority since we haven't needed to use it in the demo sketches.

[tfadali]

Were you planning to take out these lines once you implement more of the design?

You guessed it.

[GregStanton]

The map() method is more concise than the loop I used for the same method in the Square class. There are some trade-offs, but if one implementation is clearly preferable on balance, then could you go ahead and make the corresponding methods in these classes consistent? Once we get to the point where we have a third repetition of these methods, we may want to go ahead and abstract them into a base class, but for now, we could skip that.

[tfadali]

I don't know if we have to go with 100% loops or 100% functional-style .map() stuff. For example, at my last job, we had the convention of using loops whenever the internal code mutated some state, and preferred functional-style for most other cases. Sometimes, for more complicated cases, a loop will be much easier to deal with.

[tfadali]

But yeah, we can make it consistent between methods that do the same thing and/or combine them into common abstract methods.

[GregStanton]

I guess you hard coded 5 temporarily?

[tfadali]

Yeah, just getting it working for now.

[GregStanton]

Maybe the midpoint doesn't need to be displayed? Or if it does, would it take long to replace the hard-coded 3 with something else? It might be okay for the sake of the prototype.

[tfadali]

Midpoint display is to help indicate that you can drag it if your mouse is over that point.