Un-deprecate File::separatorString


#1

Hi,

Can you please un-deprecate File::separatorString?

Juce 5 deprecates File::separatorString (using the JUCE_DEPRECATED macro) which causes a compilation warning in code which uses it. It is deprecated in favor of File::getSeparatorString(), which is only available in Juce 5. This means there is no grace period for transitioning from the older API to the new one. That’s a problem; if you have some library code which is common to a few plug-ins, and not all of them have migrated to Juce 5 yet, you would have to either:

  • Keep using the old API and get warnings in the Juce 5 projects (or disable the warnings using pragmas, ugly and defeats the purpose of the deprecation)
  • Make your own wrapper function which would use the older API for Juce 4 projects, and the newer one for Juce 5 projects - puts an unnecessary burden on the programmer and creates boilerplate code to maintain.

Thanks,
Dan


#2

How do you mean? Should separatorString and getSeparatorString() coexist without any deprecation warning? How would one know that one is already doomed for deprecation? Why do you want to get rid of a warning that’s there for a purpose?

Can’t you just add the getSeparatorString() function to your juce 4 copy?


#3

Well, yes there is - that’s why we deprecate things before removing them. You warn people about it with a warning, and then later remove them.

If you have old code which you’re not updating then you could just keep building it with older versions of juce and it’d work for as long as the tools support it. Or you could maintain your old code to keep it up-to-date with newer juce versions, but that obviously means the occasional change like this.

Is it such a big deal anyway? When I made this change, it only took a couple of minutes to update our whole codebase, as it’s a really rarely-used thing… (Or it should be if you’re using the File class correctly!)


#4

I think this is a legal question to which the answer is probably “No”. In a scenario where you bought a commercial license to JUCE 4 and are trying to evaluate JUCE 5 and have not yet decided about it (haven’t bought a commercial license for it), you are probably not allowed to add a JUCE 5 function to JUCE 4.

How do you mean? Should separatorString and getSeparatorString() coexist without any deprecation warning? How would one know that one is already doomed for deprecation? Why do you want to get rid of a warning that’s there for a purpose?

Let’s see some examples -

Django:

A feature release may deprecate certain features from previous releases. If a feature is deprecated in feature release A.x, it will continue to work in all A.x versions (for all versions of x) but raise warnings. Deprecated features will be removed in the B.0 release, or B.1 for features deprecated in the last A.x feature release to ensure deprecations are done over at least 2 feature releases.

The warnings are silent by default. You can turn on display of these warnings with the python -Wd option.

Similar to Python’s -Wd option, Haskell has -Wcompat:

Turns on warnings that will be enabled by default in the future, but remain off in normal compilations for the time being. This allows library authors eager to make their code future compatible to adapt to new features before they even generate warnings.

Taking this approach, the old method can have a deprecation warning that only triggers when you enable some flag. Then at some future version this deprecation triggers by default and at a later version the old method is removed.

And to make it work best, either the deprecation cycle is extremely long as in the case of Haskell, or like in Django they maintain bugfix releases for old LTS versions, not forcing anyone to upgrade.


#5

Both these points are irrelevant because as I wrote above I’m talking about library code which is common to a few plug-ins, not all of which have migrated to Juce 5 yet. That code should keep working in both Juce4 and Juce5 projects, without warnings. That’s why I’m stuck with the not-great options of handling it which I mentioned above.

I did try another workaround which is turning on JUCE_NO_DEPRECATION_WARNINGS, but then juce_MathsFunctions.h doesn’t compile; this just needs to be fixed. It’s not an ideal solution, though, anyway, since I do want to be warned-by-default about deprecations, but only later in the deprecation cycle, like it’s done in other frameworks, as Yair describes.


#6

Sure, and that’s something that we should sort out!