Counter-Proposal: restrict & tagged functions

foobar foo at bar.com
Mon Sep 3 11:18:36 PDT 2012


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.



More information about the Digitalmars-d mailing list