Open pfitzseb opened 8 years ago
I vote for TkText definition. Currently including Tk breaks way too many other things by overriding Base.Text.
Why is Base even exporting Text
? That seems internal to the Markdown parser and not a type users should need to work with very often.
Right, so should we rename Tk.Text
, unexport it from Tk
or unexport Text
from Base?
All of the above?
which causes issues when using Atom.jl when importing Tk.jl in user code.
Ref: https://github.com/JunoLab/atom-julia-client/issues/118
The solutions I see would be to either
Text
and require the user to useTk.Text
or maybe defineTkText
orWidget
not includeAbstractString
and instead useTkWidget(x::AbstractString)
or something similar.Edit: And since the second half of this issue doesn't appear for mysterious reasons (actually, most likely a forgotten Ctrl+Enter...):
Text{typeof(x)}(x)
everywhere in Atom to use the parametric constructor from Base, but that seems oh so ugly. Maybe there's another way to enforce using a specific constructor?I'm not sure if there's any kind of guideline for overwriting types from Base, but Tk's behaviour seems kinda strange to me. If there's something we can/should change on our side, I'd be glad to do it -- otherwise I'd be happy to implement some change in Tk as well.