Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

get/setSize types disagree #117

Open
mitchellwrosen opened this issue Apr 23, 2019 · 5 comments
Open

get/setSize types disagree #117

mitchellwrosen opened this issue Apr 23, 2019 · 5 comments

Comments

@mitchellwrosen
Copy link
Contributor

getSize :: Ref _ -> IO Int
setSize :: Size -> IO ()
@mitchellwrosen
Copy link
Contributor Author

Whoops, I could be wrong about this one. I forget what widget I was looking at when I made the ticket, but for the Input widget, it really does have

int Fl_Input_::size() const
void Fl_Input_::size	(int W, int H)		

@mitchellwrosen
Copy link
Contributor Author

(heh, because getSize gets the length of the text whereas setSize sets the size of the widget)

@deech
Copy link
Owner

deech commented Apr 24, 2019

Ah yes, that makes sense. And actually this OO overloading (specifically being able to have two methods with the same name and completely different type signatures) that's common place in C++ is quite difficult to deal with Haskell and motivated most of the design. None of the existing literature addressed this. The gi-* packages use OverloadedLabels but that's a dangerous extension and I didn't want that in the codebase. OverloadedRecordFields could be a good step forward but I haven't had the time and the migration effort is pretty significant.

@mitchellwrosen
Copy link
Contributor Author

Yup, very tricky to design around in Haskell for sure. I've been working on a simplified interface to fltkhs that probably will never become complete enough to release, but I do think there is enough complexity in fltkhs to warrant an opinionated Haskellier wrapper that trades power for simplicity.

@deech
Copy link
Owner

deech commented Apr 24, 2019

Totally! Here to help if you need it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants