In response to Kaioken
I'm liking that idea, actually. It'd certainly reward people who saw making libraries as more than a fire and forget exercise.

For example, if one of Fizz's libraries was broken by a feature change, I have a feeling I'd get an update pretty quick, and people using rival libraries would move to use his too, during their own development process. BYOND bends over backwards to support "just enough" people already, the language too shouldn't have to pay an evolution penalty for it.
In response to Tom
Any chance of providing an option (via #define, or command-line argument) to disable backwards compatibility features of the compiler? I'd much rather get errors instead of warnings and magic behavior.
In response to Falacy
Falacy wrote:
It seems like you've used just about every naming convention available, without any type of consistency. Just whatever you were working on one day fell into a specific method, and then next day was a new one.

Although (as DarkCampainger linked), there is some method to the madness, I basically agree with you. Not only is the naming convention inconsistent, but the names themselves are often confusing (html_encode comes to mind). Some of the procedures use prefixes (winget), some suffixes (cmptext) and some are object-oriented.

Unfortunately, because the issues are so rampant, it would require a radical redesign to set things straight. Furthermore, the proper approach would be to object-orientize all procs so they'd be more easily organized; eg, having a /text node and attaching implicit procs like text.Upper(), and that requires a lot more work. Maybe in BYOND 5.

As far as cmptext etc, I've long felt that have case-centric versions of functions is needlessly confusing. However, to be consistent with our existing convention we should have used _ex (or _exact) instead of Ex. I didn't consider that since I use the uppercase word boundaries for my own code (which is probably why cmptext/cmpText feels particularly error prone to me), but now I see that these are the only procs that use this convention. Maybe in the next release we'll just support both forms.
In response to Slurm
Slurm wrote:
Any chance of providing an option (via #define, or command-line argument) to disable backwards compatibility features of the compiler? I'd much rather get errors instead of warnings and magic behavior.

Do you mean a setting to treat warnings as errors? We could do that.
In response to Tom
I would like #define PEDANTIC, although I'm not sure if Slurm just wants it for deprecation warnings.
In response to Tom
Tom wrote:
Do you mean a setting to treat warnings as errors? We could do that.

While an option to treat warnings as errors would most certainly be cool, I was thinking more along the lines of having any backwards compatibility features being completely disabled.
In response to Tom
Tom wrote:
Slurm wrote:
Any chance of providing an option (via #define, or command-line argument) to disable backwards compatibility features of the compiler? I'd much rather get errors instead of warnings and magic behavior.

Do you mean a setting to treat warnings as errors? We could do that.

I like this idea, actually.
Page: 1 2