On Behalf Of E. Gladyshev Sent: Friday, 2 April 2004 1:34 PM To: boost@lists.boost.org Subject: Re: [boost] Re: Policy or Trait?

From: "Hurd, Matthew" <hurdm@sig.com>

[...]

...

It would be nice if something new like "aspect class" or some such could

Interesting name! I second your opinion in many ways.

Would be nice to stop the confusion / confounding by describing somewhat rigorously a classification / nomenclature for "aspect classes". Constant aspects (bad name?, plain? simpleton?) - static constants and types only (bad name) Static aspect - constant aspect extended to include static methods Base aspect - intended to be inherited from by a client aka common MCD policy class - policy aspect perhaps? Chain aspect - not sure how to describe this Recurring base aspect - a base aspect that requires the first parameter to be the client class, this is the CRTP. Generic "blah" aspect - "blah" parameterised by additional template parameters beyond the client e.g. generic recurring base aspect is the CRTP with additional params A generic base aspect class would describe much of the MCD style policy classes. A static aspect could be used in a base aspect like manner or without the inheritance. "Aspect" might be inappropriate as I'm not 100% on my AOP nomenclature, but it feels appropriate. A trait or policy could be classified in such terms which might avoid some confusion. Needs some work, but it might start something...

I don't think that differentiating between traits and policy makes too much sense or really necessary. As for now to me, they both are parts of the same concept. The idea is that a class can define an API specification. The user is responsible for implementing the API and supplying the implementation to the class as a template parameter.

Traditionally an API is not a set of just behaviors or just data structures. It is a combination of both and it doesn't have to be stateless.

So what's so unique about API's from the OOP standpoint especially. Well, an API as such cannot be INSTANTIATED. It just EXISTs as a set of rules, etc. It is like namespaces in C++. You cannot instantiate a namespace! You can instantiate data types defined by the API though.

So to me, both traits and policies are sort of interchangeable namespaces. Perhaps my view is too simplistic.

I sometimes do something like this

template< typename MatrixApi > struct equation_system_solver {...};

struct api { private: //** note private here api(); };

struct my_vector_api : api {...};

template< typename VectrorApi > struct my_matrix_api : api {...};

equation_system_solver< my_matrix_api<my_vector_api> > s;

Interesting. Especially handy I'd imagine if you use the CRTP with the api to give yourself some static polymorphism. Another pattern trait / policy style pattern I've used recently is having integer offsets and types associated with names in a type that represents a packet type, these "aspect classes" are combined with a packet type in a client to handle different financial exchanges in my case. This would be a "constant aspect" in my nomenclature above. It is a trait of a concept rather being a trait of a specific type or class. Gets interesting when one of those types in the constant aspect is a static aspect that describes operations on the type to be found at the offset indicated. The packet aspect is really nothing much more than a bunch integers and associated types and it feels like a trait (it is a trait of a concept); it is used like a policy. $0.002 Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm@sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.