Comments (5)
Related PR: #121
from binary-compatibility-validator.
It seems like regular expressions could be too heavyweight (conceptually, not in terms of performance overhead) for this particular problem. Would wildcards (like *
and ?
, or even ant-style globs with **
) solve the problem or are there some practical cases where it's not enough to specify the *
?
from binary-compatibility-validator.
Would wildcards
Strong opposition to wildcards. Regex has documentation and years of battle tested usage. Most developers should be familiar with Regexes.
Wilcards have different implementations (shell, ant, other?) and it's impossible to tell what to expect without reading through (sometimes absent) documentation.
Plus regexes are more flexible. Sorry for the upfront response but I've been burned too many times 😅
from binary-compatibility-validator.
The flexibility regexes have comes with complexity and it's easy to make a mistake. When applied to package names, it may be too cumbersome to escape every dot in the name to get a semantically correct RE.
Wilcards have different implementations (shell, ant, other?) and it's impossible to tell what to expect without reading through (sometimes absent) documentation.
One still has to read documentation to figure out if the expression like ignoredPackages += "\.*\.internal"
will match the whole input or only a subsequence.
With wildcards having only *
in the grammar, it should be possible to express basic package-related patterns without keeping complex grammar rules in mind. I believe that we are all used to treating *
as the Kleene operator, so there should not be that much ambiguity.
From the API point of view, wildcards allow us to continue using the same ignoredPackages
property to specify both literal package names and wildcards (let's pretend that there are no packages with *
in their names 😨). For regexes, the new API has to be introduced, otherwise, users have to escape all their existing ignoredPackages
to preserve the semantics after update.
from binary-compatibility-validator.
One question is: "does *
match .
?"
If I want to ignore com.foo.internal
and all subpackages, do I have to ignore com.foo.internal
and com.foo.internal.*
(and potentially com.foo.internal.*.*
?). Can I just ignore com.foo.internal*
(but then it might be surprizing to someone that adds com.foo.internalization
?).
I've been there with dexguard and to this day I won't be able to tell you if a dexguard rule matches a class name from memory. I wish all string matching used regexes so that I don't have to fit new rules in my brain.
Now the BCV use case is probably simpler and you're 100% right about new API. Using just ignoredPackages
wouldn't work. I have updated the initial comment to use ignoredPackagesRegexes
.
So at the end of the day, it's a tradeoff that also depends on personal preferences. Both work for my immediate use case so I'll be happy no matter what :). Thanks for looking into this!
from binary-compatibility-validator.
Related Issues (20)
- BCV Gradle Plugin should not depend on kotlin-compiler-embeddable HOT 1
- BCV tasks do not work for a project with generated sources when configuration cache is enabled
- org.gradle.api.InvalidUserDataException? HOT 2
- @JvmOverloads doesn't generate different methods for compose functions HOT 2
- Klib validation DSL for Groovy is different HOT 1
- Removal of default parameter is binary compatible but breaks runtime HOT 3
- `public` members of non-API supertype should be visible in the inheritor
- Unknown native target errors with Kotlin 2.0.0-RC1 HOT 4
- `KlibSignatureVersion.LATEST.toString()` is rendered as `KlibSignatureVersion(-2147483648)`
- Add Gradle version compatibility tests HOT 2
- Consider moving BCV to Kotlin repo HOT 3
- Description of a Syncs API task is uninformative HOT 1
- Add brief description to the top of .api dumps, to help explain the file and BCV
- Remove case-insensitive dump file names handling logic HOT 16
- Merge JVM and KLib ABI dumps into a single file
- Use a project/module-agnostic name for dump files
- Removing native targets did not cause API check to fail HOT 4
- Support Multi-Release JAR Files HOT 9
- allow apiDumpDirectory outside projectDir if inside rootProjectDir HOT 14
- Allow `apiCheck` to run on all subprojects before failing HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from binary-compatibility-validator.