Re: UI/IDE committee

new topic     » goto parent     » topic index » view thread      » older message » newer message

The IUP API is what it is and I have no intention of changing it to fit Euphoria. It's a third-party library developed by Tecgraf, and I think they've done a pretty good job of making it simple and easy to use. If we try to whittle it down even further to make it "fit" Euphoria, I think that would be a disservice to IUP, Tecgraf, and Euphoria users everywhere. It's especially concerning if someone comes to Euphoria from C with experience using IUP (or vise-versa), but then suddenly the IUP API is completely foreign because of our changes.

I certainly don't agree with stripping the IUP_ prefix from constant names. Constants should denote what they're for and where they come from. That's just good API design: How to Design a Good API and Why it Matters (PDF, 566 KB).

keynote.pdf said...
  • Names Should Be Largely Self-Explanatory (emphasis mine)
    • Avoid cryptic abbreviations
  • Be consistent - same word means same thing
    • Throughout API, (Across APIs on the platform)
  • Be regular–strive for symmetry


  • Code should read like prose

Regardless, the use of those constants, as Pete pointed out, is deprecated in IUP. A compromise I will make is that iupdef.e will no longer be included by default. Those wishing to use the deprecated constants will have to include iupdef.e manually. We should still include iupkey.e, however, because its constants and functions are required for handling keypress events.

And don't get me wrong, I've got no problem with exapanding on IUP for Euphoria's purpose, especially when we can utilize some features in the process. Default parameter values is a great example of this. And jmduro's expanded version of IupGetParam is another example.

I'm on the fence about "helping" the user convert attribute names to uppercase. On one hand, this isn't something that IUP does natively. But on the other, it is required for attributes to work correctly, but is not enforced by the library itself, which seems contradictory. I say we put it to a vote. Those interested in converting attribute names to uppercase within the IUP wrapper should mark a vote on the issue that Tom created: #5 - Lowercase Arguments (there is a "Vote for this issue" link to the right). If there are several votes by the time I get to working on that issue (at least a few weeks from now), then I will make the change.

-Greg

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu