Does it: trait A, subtraits Aa and Ab, subsubs Aaa, Aab?

[JeffreySarnoff]

[andyferris]

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!

[c42f]

Hi Jeffery! While I appreciate wit and brevity in principle, I must say I've got no idea what you're talking about :-)

[JeffreySarnoff]

Hi Chris! I have not been in Australia (would enjoy that) .. Just wondering if what traits may become lets us qualify a traited concept by using subordinate traits as qualia collectors or subobject classifiers. (like shallow abstract type hierarchies ending with leaf types without the leaf types so every traited thing remains available to become made conceptually clearer by augmenting the thing with more nuanced traithood.

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

[JeffreySarnoff]

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 passing of tests to ensure Protocal conformance.

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 -- --- and when registered, that should suggest my type when perceived as a qualified Protocol should be given moredetail by becoming also entraited MachineImplementedBinary.