I usually try to organize related things in different files in the same
order to ease code reviewing, reading and writing new code. For example:
order of protocol method declarations, their definitions in records and
unit tests. And I was wondering what's the best way to order keys in maps
and
I find closed keys specs generally easier to work this (e.g. it protects
from cases when I forget to spec some new data returned from the function).
In my current project the number of open keys specs is ~1.5% and they're
are for entities where the shape is really unknown beforehand. At the
mom
I've never used defn-, ^:private, etc. But I rigorously prepend a prefix to
mark private things, e.g.
`-this-is-private-and-can-only-be-used-in-current-file`. From my
experience, it makes reading/maintaining code much easier, in any
programming language. I think I borrowed this convention from
definition time would break recursive specs.
>>>>>>
>>>>>> As one of the (apparently pretty uncommon) users who actually does
>>>>>> happily define s/keys specs without correspondingly speccing the leaves
>>>>>> as
>>>&
Thanks. This approach is also different from the macro because it will
check specs existence at the validation time, not at the s/def call.
On Wednesday, October 4, 2017 at 4:18:16 PM UTC+3, Moritz Ulrich wrote:
>
> Yuri Govorushchenko > writes:
>
> > Thank you the pointers!
ill pass, not sure about the use cases
though)
- only if spec for key is registered (current behavior)
- always validate values (should fail if there's no spec for value
registered)
Thanks.
On Tuesday, October 3, 2017 at 6:43:56 PM UTC+3, Alex Miller wrote:
>
>
>
> On Tuesday,
be supported (currently: out of scope), I
> think we could go even further - we could rewrite conform* as walk* to
> support all of fast coercion, explain and conform. We are using conform +
> unform as a substitute of coercion but sadly, it's quite slow, especially
> for maps.
&
rg values at keys in
the same way `s/cat` checks arg values at positions.
On Tuesday, October 3, 2017 at 6:01:06 AM UTC+3, Alex Miller wrote:
>
>
>
> On Monday, October 2, 2017 at 10:37:31 AM UTC-5, Yuri Govorushchenko wrote:
>>
>> Hi!
>>
>> I have some
>> easily happen if you have a typo in the spec.
>>
>> Also we never experienced benefits from being able to not spec keys
>> required in s/keys. It appears to be a pretty obsolete feature, making
>> vulnerabilities more likely.
>>
>> On Monday, October
Hi!
I have some noobie questions for which I couldn't google the compelling
answers.
1) Is there any way to ensure that the keys I used in `s/keys` have the
associated specs defined? At compile time or at least at runtime. Maybe via
an additional library? I could imagine a macro (smt. like `s/
Hello,
I wonder, will it be possible to add specs to defprotocols? I use protocols
a lot and it would be very handy to be able to instrument protocol methods.
It is something Plumatic Schema cannot do at the
moment: https://github.com/plumatic/schema/issues/117
Thanks.
--
You received this m
I recall Google uses vertical bars in ObjC comments for similar purposes,
as stated in their style guide:
Use vertical bars to quote variable names and symbols in comments rather
than quotes or naming the symbol inline.
This helps eliminate ambiguity, especially when the symbol is a common word
Hi! This is the first public release of my lib for mocking and stubbing in
unit tests, I would greatly appreciate any feedback.
GitHub: https://github.com/metametadata/clj-fakes
Documentation: http://metametadata.github.io/clj-fakes/
*Features*
- All test doubles are named "fakes" to simp
Hello Alexander, Marc,
Ah, now I get this. Thank you for your responses!
вторник, 21 июля 2015 г., 17:54:42 UTC+3 пользователь Yuri Govorushchenko
написал:
>
> The problem I'm trying to solve is how to stub a variable (e.g. a function
> from a third-party lib) in tests so tha
orgon
>
> On Tuesday, July 21, 2015 at 10:54:42 AM UTC-4, Yuri Govorushchenko wrote:
>>
>> The problem I'm trying to solve is how to stub a variable (e.g. a
>> function from a third-party lib) in tests so that the stubbing occurs only
>> in the current thr
The problem I'm trying to solve is how to stub a variable (e.g. a function
from a third-party lib) in tests so that the stubbing occurs only in the
current thread with other threads continuing using var's root value. It's
important because unit tests may be run in parallel. Without thread-local
16 matches
Mail list logo
