-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does it: trait A, subtraits Aa and Ab, subsubs Aaa, Aab? #6
Comments
Umm... traits have been designed to be single-level at the moment in traitor. So you have an abstract trait class and a bunch of concrete traits that inherit from it directly (not sure on the correct terminology between classes, traits and subtraits?). You possibly could use more levels but I haven't investigated what the code would do - it might "just work". Traits with parameters possibly work, though I'm not sure the macro will work with them or not. To be honest, Traitor needs some serious love before it would be really usable. And user testing/feedback! |
Hi Jeffery! While I appreciate wit and brevity in principle, I must say I've got no idea what you're talking about :-) |
Hi Chris! I have not been in Australia (would enjoy that) .. pretend its Julia: trait Dimensional
traits D1, D2, D3, D4 <: Dimensional
trait Geometric
trait Shapely <: (Geometric, Dimensional}
traits Circular, Triangular, Squareular, <: (Shape, D2)
traits Spherical, Pyramidal, Cubic <: (Shape, D3)
type GeoForm{S<:Shape}
shapeliness::S
...
end
BeachBall = GeoForm( Spherical, ... )
...
trait FloatationDevice
BeachBall ↤ FloatationDevice |
I think the cleanest careful + powerful approach to implementing Protocols (which seem to be on track as the meta-ultra-wonder-way of realizing the personal simplicity of growing software API) uses orthogonal, evolvable sets of traits and trait-decoratable traits --some that are not for the taking, rather they are given with the So if I write a Protocol for extended precision floating point types that protocol is embued with the traits NumericalProtocol, RealNumber, MachineImplemented because the community prefers it so and also the trait ExtendedPrecisionFloatingPoint because the Protocol has that modular name. Then if I write an extended precision floating point type that is designed to show calculated numbers as clearly as possible -- as informing and non-misleading a string as is knowable, then that type is written to cleave to the ExtendedPrecisionFloatingPoint Protocal and introduces a trait reflecting its unique contribution -- TransparentValuation. Now the next person who wants to use a decimal version of this will write code to the qualified Protocol {ExtendedPrecisionFloatingPoint, TransparentValuation} and add MachineImplementedDecimal -- |
No description provided.
The text was updated successfully, but these errors were encountered: