[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sc-devel] [3.2] suggestion: compiler directive for class library



Sometimes it's necessary for one third party library to include extensions for another third party library, but you can't always guarantee that the other library is going to be installed. Dependencies in quarks help if both libraries are quarks, but if not (such as SwingOSC), it gets really inconvenient.

If someone installs the ddwGUIEnhancements quark and they don't have SwingOSC, these errors show up during library compilation:

• ERROR: Class extension for nonexistent class 'JSCContainerView'
     In file:'/Users/dewdrop/Library/Application Support/SuperCollider/Extensions/quarks/dewdrop_lib/ddwGUIEnhancements/SwingOSC-recursiveResize.sc'
• ERROR: Class extension for nonexistent class 'JSCView'

The first problem is that this isn't really an error. The library compiles and you can use SuperCollider even with the "error" -- so it should really be at most a warning. I would like to think this is purely cosmetic, but unfortunately most users don't (even some experienced users). They see a so-called "error" during compilation and then they think I've done something horribly wrong, when the reality is that I'm making the most of a difficult situation. Even warnings provoke anxiety (witness responses onlist to the "function not inlined" warning).

Okay, I'm making it personal, but really this affects anybody who wants to create GUI extensions that require both cocoa and swing methods.

Currently the only solution I can think of is pretty well unsatisfactory. I could create a separate quark containing only the swing extensions. But that doesn't remove the confusion. To satisfy cocoa users, it should not be installed as a dependency for dewdrop_lib -- but then, I can expect e-mail from SwingOSC users complaining that they installed my library and certain GUI functions don't work. Catch-22. The readme is not much of a solution because people don't read them carefully.

What do you think about having some kind of compiler directive to handle this more intelligently? The simplest I can think of is to suppress non fatal compilation errors until the end of the file. (Obviously fatal errors must be reported in all cases.) When you're developing, you might want them to be reported, but for release, there are legitimate cases where you might not reasonably be able to avoid every non fatal error, and there is no reason why the user should be troubled.

Maybe a special comment?

//#WARNINGS-OFF

+ JSCView {
...
}

//#WARNINGS-ON

If we could resolve this before the book is published, that would be really helpful because probably more people will install my libraries and it would be really nice not to have to tell one group of users, "well, sorry, it's going to be just a bit more complicated for you."

Thanks.
hjh


: H. James Harkins

: jamshark70@xxxxxxxxxxxxxxxxx

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:


"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman