2 posts tagged with "release"

Inheritance is one of OOP’s most powerful tools, but also one of its easiest to misuse. When applied in the wrong places, it can create internal dependency hell.

Yet Wraplet does provide base classes with basic implementations of the Wraplet API that users can extend. They are thin, sure, but I never wanted to force them on people using Wraplet. That's why Wraplet API is encapsulated in a single property, and can be created manually on any class, so anyone who wants to avoid inheritance can do so completely. The Wraplet API can be created by calling a single function: createWrapletApi. You can hook into the wraplet's lifecycle by passing lifecycle callbacks to it.

Hard to make it simpler than that, right?

I'm thrilled to announce the release of the 1.0.0-rc.1 version.

So what does this mean for you? It's a pledge that there will be no further BC breaking API changes. The API you build on today is the API you can rely on.

Why am I confident enough to commit to that? Because Wraplet is (and has been for quite some time already) 100% covered with tests, including branch coverage. It was tempting to push out a 1.0.0 release right away. For long-lived projects a certain caution is required, though, and it's best to exercise it from the start, so we'll move slowly and strictly follow the SemVer rules.

One thing worth clarifying: the stability pledge doesn't mean the base classes you extend are frozen solid. Within minor versions Wraplet may still add new methods and properties to them as its capabilities grow — in particular lifecycle methods whose names start with on. To stay on the safe side, treat the on prefix as reserved and avoid using it for your own methods on classes deriving from Wraplet, so a future addition can't clash with them. We'll be careful about the name clashes.