[ANN] BinaryTraits.jl - a new traits package

Package Announcements
, ,
21

Does anyone want to chime in about this breaking change? I would love to hear your perspective if you have any interest about using this package. Thanks!

https://github.com/tk3369/BinaryTraits.jl/issues/23

4 Likes
22

Hi everyone. FYI, I have just tagged a new release (0.4.0) :tada::tada::tada:

I would like to thank @Janis_Erdmanis for his persistence in pushing this parametric type idea and @klacru and @JeffreySarnoffā€™s participation in the discussions. This change would not be possible without their support.

In a nutshell, we have a new design that use parametric types. Itā€™s breaking but a lot more awesome than before. I guess a picture is worth a thousand words:

concept_defining_traits
concept_defining_traits1642Ɨ728 37.8 KB

The project documentation has been updated as well. If you havenā€™t seen it before, just take a look.

This package is growing up fairly quickly. If you have any more improvement ideas, feel free to write it here or submit a GitHub issue.

Tom

9 Likes
23

Hi there! Just want to announce that v0.5.0 release is out.

This release adds return type check for interface contracts. Return type of an interface contract is covariant i.e. the implementation must return an object of a type that is a subtype of the required return type as specified in the contract. See updated documentation about variance for more details.

Whatā€™s coming up next? I donā€™t know :stuck_out_tongue_closed_eyes: I may get some idea if you place your vote (:+1:) on any pending item in the github issues list.

6 Likes
24

:tada: Release v0.6.0 is out! :slight_smile:

A new macro @traitfn has been added to simplify writing functions that require trait arguments. Hereā€™s a quick example about the new feature.

Normally, you would have to write a dispatch function and add a trait type argument to all implementation functions like this:

# dispatcher
function fly(x::T, direction::Float64, altitude::Float64) where T
    return fly(trait(Fly, T), x, direction, altitude)
end

# implementations
fly(::Can{Fly}, x, direction::Float64, altitude::Float64) = "Having fun!"
fly(::Cannot{Fly}, x, direction::Float64, altitude::Float64) = "Too bad..."

Now, you can just write the implementation functions directly as follows:

@traitfn fly(x::Can{Fly}, direction::Float64, altitude::Float64) = "Having fun!"
@traitfn fly(x::Cannot{Fly}, direction::Float64, altitude::Float64) = "Too bad..."

Is there any use case that you may find this useful? What other features would you like?
Just ping me or file an issue :wink:

4 Likes
25

Iā€™m finally really looking into this package seriously. A quick glance at the source code and Iā€™m really impressed with the level of thought that has gone into stuff that the user doesnā€™t even know exists.

Edit: To clarify, I mean things that the user probably doesnā€™t want to know are going on either, not hidden and undocumented features. Just nice stuff under the hood.

1 Like
26

i like directions it takes

Define interface contracts for a trait

from docs, can you cumulate, for example:

@implement Can{Fly} by fly(_, direction::Float64, altitude::Float64)
@implement Can{Fly} by flyfast(_, direction::Float64, altitude::Float64)
@implement Can{Fly} by flyquack(noise::String,_, direction::Float64, altitude::Float64)

?

27

Yes, that should be fine. Note that all three methods must be implemented to be fully compliant with the Can{Fly} trait.

28

nice!!
we could give alias to Can{...]
with HasInterface{...} !!