github-linguist
DataFlex - add support for this language
Language name
DataFlex
URL of example repository
https://github.com/DataFlexCode https://github.com/NilsSve
URL of syntax highlighting grammar
https://docs.dataaccess.com/dataflexhelp/mergedProjects/LanguageGuide/Language_Guide.htm
Most popular extensions
.src,.pkg,.vw,.dg,.sl,.bp,.wo,.inc
Detected language
DataFlex
DataFlex uses a lot of different file extensions, some of which will likely have conflicts. Modern DataFlex uses a common workspace structure, such as AppSrc/cMyClass.pkg. Searching for NOT is:fork path:Appsrc/**.pkg narrows it down to effectively DataFlex source code files and provides 900+ results. Many of the other file extensions are nowhere near that many, so it won't meet the minimum usage requirements.
Given that there are so many file extensions in use, maybe a better initial approach could be to add support for DataFlex without specifying extensions or filenames to avoid conflicts. And DataFlex source repositories can use .gitattributes overrides for the relevant extensions instead. Obviously not ideal, but it would at least provide recognition for the DataFlex language, and that's a great starting point.
I see there is some precedence for languages without specifying file extensions, such as for Elvish transcripts from PR #6302, which is mainly used inside markdown files. @lildude and @NilsSve, I can help and put up a PR for adding the DataFlex language without specifying any file extensions, would that work?
Hi Sonny,
If you are asking me, yes, that would help! The current repositories at @NilsSve are using .gitattributes exactly as suggested.
I see there is some precedence for languages without specifying file extensions, such as for Elvish transcripts from PR #6302, which is mainly used inside markdown files. @lildude and @NilsSve, I can help and put up a PR for adding the DataFlex language without specifying any file extensions, would that work?
It would "work" but it won't be accepted. The Elvish exception is because there isn't a common extension as it's predominantly used in a markdown files. This is not the case with DataFlex.
I know nothing about DataFlex but wikipedia says "DataFlex is an object-oriented high-level programming language and a fourth generation visual tool for developing Windows, web and mobile software applications on one framework-based platform."
We do not add support for frameworks, hence we support Ruby, but not Rails, so the right thing to do is concentrate on only the language files. I'd expect the language to have a common extension and structure that can be identified. This should be what is added first, assuming usage meets requirements, and then users can use the overrides to classify the other extensions if they want.
If the language predominantly uses a generic extension like .pkg (poor design decision IMO), this can be added the generic.yml file and a heuristic will be used to identify the language, but be warned: this heuristic must be very accurate to only identify DataFlex files and must be linear and performant. It's better for this regex to under identify DataFlex files than misidentify other languages.
It would "work" but it won't be accepted. The Elvish exception is because there isn't a common extension as it's predominantly used in a markdown files. This is not the case with DataFlex.
I see. That makes sense. DataFlex is an old language that's been around in its current object-oriented form for 20+ years. Its use is mainly for database business applications, for Windows and web apps. It unfortunately doesn't have a single dedicated file extension, and the convention is to use one of a set of extensions representing the main purpose of the specific DataFlex source file. Such as .vw for a view, and other extensions for database business logic etc. The .pkg extension is typically used for reusable classes, which is why it's the predominant extension seen on GitHub.
If the language predominantly uses a generic extension like .pkg (poor design decision IMO), this can be added the generic.yml file and a heuristic will be used to identify the language, but be warned: this heuristic must be very accurate to only identify DataFlex files and must be linear and performant. It's better for this regex to under identify DataFlex files than misidentify other languages.
That sounds like a great idea, thanks! I will pursue this strategy for the .pkg file extension since it's the most commonly used extension. I'll follow the instructions and add it to generic.yml with heuristics and tests. Thanks again!
And may I add that DataFlex has two frameworks. One for Windows and one for the Web, with overlaps between them for datadictionaries for consistent database behaviour.
However, the frameworks are not optionals/add-ons like in many other languages. Instead they are an integrated part of the DataFlex language. And they are written in the DataFlex language.
Sure, a web-based DataFlex application also uses javascript libraries and many other parts needed for a modern webapp, but those files are not part of the frameworks. The build in frameworks are more guided towards how to develop applications more easy, fluently and make the code more robust and easier to follow.