lower case widget functions? about interact.jl HOT 8 CLOSED

The convention is that constructors should be named like the types. The lower-case versions, like int(...), are things that are (a) more coercive in conversions (no InexactErrors) and (b) may not return the corresponding type. e.g. int([1.0, 3.7]) works and returns an array of integers. See also JuliaLang/julia#1470.

So, in keeping with this convention, you should keep the constructors as uppercase, i.e. Slider(...) and not slider(...). Hence, my vote is to revert this patch.

from interact.jl.

On the other hand, a function like widget(foo) which automatically constructs a slider for a range foo and a checkbox for a boolean foo, as discussed as #11, should be lowercase, since widget returns some arbitrary subtype of Widget.

from interact.jl.

see #16...

from interact.jl.

I don't see how #16 is related to this. I'm just saying you should revert the case-change patch and make the Checkbox constructor checkbox, to follow Julia conventions.

How you store widget options has nothing to do with whether you capitalize the constructor.

from interact.jl.

The proposal in #16 eliminates the need for various widget types like Slider, Checkbox, instead replaced by InputWidget{:Slider}, InputWidget{:Checkbox} and so on, since they all will have the same two fields: options, signal. If I revert the patch now, and later go for a design such as #16, we are going to have to break existing notebooks which use Slider and Checkbox...

from interact.jl.

@stevengj Oh, slider and checkbox will still be constructors in that they consrtuct InputWidgets so the convention is Slider and Checkbox? Will revert this if so.

from interact.jl.

Oh, I see. Yes, I suppose lower-case versions make sense then. But then why do you need slider and checkbox at all if you have widget(x; options) to construct various types of InputWidget?

from interact.jl.

slider for example provides default values for some of the arguments like value=median(range).

from interact.jl.