dionisiydk / statespecs Goto Github PK

All the DSL messages in the expressions protocol of SpecOfShouldExpression do ^ self verify: … as if that was intended to return something useful, but verify: does not return the validation result, it only raises it, which looks like an oversight.

I have a use case where I'd like to gather the results of multiple validations for an object instead of immediately complaining about the first one in evaluation order. This would allow to report a list of diagnostics, maybe after selecting the most critical ones.

Replace class words DSL with with Any expressions

• Any object
• Any kindOf: Point.
• Any instanceOf: Point
• Any containingItem: 10.
• Any emptyCollection

It would avoid the explode of new classes to support DSL for new specifications. And it looks quite readable.

Possibility for better DSL to compose specs together:

• (Any instanceOf: Point) or instanceOf: Array
• (Any instanceOf: Array) which containing: 10

Maybe something like this should be added to the docs? Or am I misunderstanding how this is supposed to work?
...
To add your own class-specific messages, subclass SpecOfShouldExpression and redefine MyDomainObject>>#should to use your subclass. The one caveat is that it seems if you send SpecOfShouldExpression class>>#startingAt:, the global pragma/object setting described in SpecOfShouldExpression's class comment will prevent your subclass from being used. To work around this, just skip that message and define your message thusly:

MyDomainObject>>#should
	^ MyCustomShouldSpec withReceiver: self asShouldExpressionReceiver

Surely this can't be right 🤔

Interval >> checkStateSpecsOrderedEqualityTo: anotherCollection

	^self checkStateSpecsOrderedEqualityTo: anotherCollection

To remove duplication of specs API in Any class it can be transformed to global object being an instance of normal spec class like SpecOfAnyObjectState

Following expression can be very useful to validate every item in collection:

#(1 2 3) where each should beKindOf: Number

Current implementation of spec inverting logic is not nice. It requires another pass to clean it and refactor with better naming

Currently the logic of should receivers composition are not part of specs.
Maybe it is better to reify ValidationSubjects as part of specs implementation.
It could simplify some part of design

Now there are two messages:

• stringForSpecValidation
• stringForSpecTitle.

It requires another pass on implementors to cleanup them. Maybe better names should be introduced