RE: [boost] Re: Policy or Trait?

From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2004-04-02 00:32:42

> On Behalf Of E. Gladyshev
> Sent: Friday, 2 April 2004 1:34 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: Policy or Trait?
> 
> 
> From: "Hurd, Matthew" <hurdm_at_[hidden]>
> 
> [...]
> > 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_at_[hidden]
+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.