On Monday, 3 September 2012 at 16:21:08 UTC, Maxim Fomin wrote:
The question with this approach is follows: if attributes are
just another way of deriving why not use old syntax?
I think you conflate two concepts - the custom attributes
_themselves_ can use the old syntax for polymorphism and reuse.
This is however completely orthogonal from the action of
attaching a custom attribute to an object (function, variable,
type, etc). This is close to AOP and cross cutting concerns.
an example (perhaps a bit convoluted, just to illustrate a point):
// I want to have all my logging related code in one place.
class Log : Attribute {}
// inheritance of attributes
class LegalLog : Log {} // for legal department
class DeveloperLog : Log {} // for developers
// usage
@LegalLog(params)
class Foo : Bar {}
@DeveloperLog(params)
class Goo : Foo {}
The idea is that all the specifics of logging are concentrated in
one place and not spread throughout the application. Say I want
to change logging file format, I can do it by simply changing the
relevant attributes without touching the main business logic of
my application. It make no sense in this scenario to derive my
business object classes from the Logging classes.
