With 4.0.2, I now get the error, “Function names can’t start with a capital letter.” I rolled back to 4.0.1, no problem. Did function names with capital letters get dis-allowed in 4.0.2? If so, can you re-enable them—I have a lot of functions.
Yes they were disallowed in 4.0.2 see this Refuse to define functions starting with a capital letter. by emlyn · Pull Request #3140 · sonic-pi-net/sonic-pi · GitHub
Apologies - this is a good example of undocumented functionality that changed between releases. I hope it’s not too much of an issue to change your functions to start with lower case letters.
This was a change based off feedback from a school teacher. Essentially starting a function with a capital letter is not expected behaviour in Ruby and whilst it is sort-of supported it does require you to explicitly use parenthesis for the arguments where typical Ruby functions let you omit them. Forcing functions to start with lower case letter stops this different behaviour and reduces the number of chances things can break in unexplainable ways in the classroom.
Please, I beg for mercy: I have 96 functions in my FASILITU library. With all due respect to the other schoolteacher, I am also a schoolteacher. Good and clear naming of my functions aids in self-documenting my 7000 lines of code. I use a consistent system of camel case, and even have some function names of a single letter, where the capital is meaningful in a musical context. Please don’t impose such a radical change. Please allow the user the option to work “dangerously” if desired and provide an option for function names that begin in lower case.
I’m not sure what you mean here. I have functions that start with capital letters whose arguments don’t require parentheses when I call them.
It’s not just my large library, but all the pieces I’ve written that use my library. The number of search-and-replaces I’d have to do would be a bear. I also have important function name families that begin with acronyms (such as “ANS” and “MTS”) because they relate to specific categories of use (e.g. “MIDI Tuning Standard”) that helps a lot with self-documentation. I have a lot of code and functionality to keep in mind over a long period of time. The point is this sudden requirement for Ruby purity–tossed off with no warning or discussion in a minor version change, no less–is just too much. Again, I beg for a live-and-let-live solution where the user can decide whether to impose the restriction or not.
It looks like Ruby only requires the parens on initial-cap functions when no arguments are used (so you can’t call Foo, but have to use Foo()).
Maybe define could only throw an error when it expects no arguments? Although that might get a bit more tricky in the case of optional arguments.
Alternatively, what about changing the error into a warning? The only issue here is it might flood the output with warnings if the fn is called in a tight loop - maybe limit it to print the warning once per run?
I had a look, and it’s easy enough to check how many required arguments a code block has, so I propose relaxing the constraint to only apply to functions that have no required arguments (PR here).
I wonder if we should just print out a warning to the log when this happens rather than raising an exception.
In any case, in the interests of just getting along, I’ve now converted everything important to me to initial lower case, figuring I can mop up the rest whenever they throw an error.
That might be safer, I’ll change my PR to generate a warning - what’s the preferred way? Is it to use __delayed_warning?
1 Like