Jump to page: 1 2
Thread overview
pure, safe and generalized attributes
Apr 04, 2008
Knud Soerensen
Apr 04, 2008
Janice Caron
Apr 04, 2008
Leandro Lucarella
Apr 04, 2008
bearophile
Apr 05, 2008
Knud Soerensen
Apr 05, 2008
Knud Soerensen
Apr 05, 2008
Janice Caron
Apr 05, 2008
Knud Soerensen
Apr 05, 2008
Janice Caron
Apr 05, 2008
Knud Soerensen
Apr 05, 2008
Janice Caron
Apr 09, 2008
Georg Wrede
Apr 04, 2008
Koroskin Denis
Apr 05, 2008
Knud Soerensen
Apr 04, 2008
David Wilson
Apr 05, 2008
Knud Soerensen
April 04, 2008
With all the talk about pure, safed and transitivity.
I think the time is right for a discussion about
user defined code attributes.

Code attributes is just meta data for the code.
Normally, this meta data is stored in revision systems, databases, in
the code comments or just plain left out.
But there is some advantages by placing them in the code and letting the
compiler take care of them.

Scott Meyers does a good job of introducing the subject in http://video.google.com/videoplay?docid=-4728145737208991310

----

The simplest use of code attribute I can imagine
is a attribute which indicate that this piece of code have been review.
It could be defined by.
attribute KilroyWasHere;

and used like
int func(param p1) KilroyWasHere
{
...
}

You can do this with comments as well, but imagine you use.

attribute FixMe warn;

and the compile gave you a warning every time it sees the FixMe attribute.

attribute FixMe fail;

Would give you a error and the build would fail.

----

The next attribute indicate that the code is license under the GPL.

attribute GPL transitive;

Here the transitive keyword tells the compiler that the attribute is transitive, and the compiler should check that every function called also has the attribute GPL.
----

attribute LGPL deny GPL;

This attribute is not transitive but the code should not call GPL code.
-----

attribute safe transitive allow pure;

Define an attribute for thread-safety which is transitive but also allows pure functions. pure would be a build in attribute because it need to be able to validate the code.
-----

Now imagine a big team need to refactor a big ugly code base.

Then the following attributes will allow the team to mark the code after how it smells (good, okay or bad);

attribute good transitive warn;
attribute okay transitive warn allow good;
attribute bad transitive warn allow okay,good;

The attributes only issue warnings, so they wouldn't stop the code form compiling, and only when more smelly code is called.


I hope that I have illustraded that user definded code attributes could be very useful.

Knud
April 04, 2008
On 04/04/2008, Knud Soerensen <4tuu4k002@sneakemail.com> wrote: <snip>

Nice. But to avoid accruing an infinite number of keywords, the syntax needs to be slightly changed. Instead of

    int func(param p1) KilroyWasHere
    {
        ...
    }

use

    int func(param p1) attribute(KilroyWasHere)
    {
        ...
    }
April 04, 2008
Good, but I'd rather see 'thread-safe' built-in attribute.

On Fri, 04 Apr 2008 11:19:49 +0400, Knud Soerensen <4tuu4k002@sneakemail.com> wrote:

>
> With all the talk about pure, safed and transitivity.
> I think the time is right for a discussion about
> user defined code attributes.
>
> Code attributes is just meta data for the code.
> Normally, this meta data is stored in revision systems, databases, in
> the code comments or just plain left out.
> But there is some advantages by placing them in the code and letting the
> compiler take care of them.
>
> Scott Meyers does a good job of introducing the subject in
> http://video.google.com/videoplay?docid=-4728145737208991310
>
> ----
>
> The simplest use of code attribute I can imagine
> is a attribute which indicate that this piece of code have been review.
> It could be defined by.
> attribute KilroyWasHere;
>
> and used like
> int func(param p1) KilroyWasHere
> {
> ...
> }
>
> You can do this with comments as well, but imagine you use.
>
> attribute FixMe warn;
>
> and the compile gave you a warning every time it sees the FixMe attribute.
>
> attribute FixMe fail;
>
> Would give you a error and the build would fail.
>
> ----
>
> The next attribute indicate that the code is license under the GPL.
>
> attribute GPL transitive;
>
> Here the transitive keyword tells the compiler that the attribute is
> transitive, and the compiler should check that every function called
> also has the attribute GPL.
> ----
>
> attribute LGPL deny GPL;
>
> This attribute is not transitive but the code should not call GPL code.
> -----
>
> attribute safe transitive allow pure;
>
> Define an attribute for thread-safety which is transitive but also
> allows pure functions. pure would be a build in attribute because it
> need to be able to validate the code.
> -----
>
> Now imagine a big team need to refactor a big ugly code base.
>
> Then the following attributes will allow the team to mark
> the code after how it smells (good, okay or bad);
>
> attribute good transitive warn;
> attribute okay transitive warn allow good;
> attribute bad transitive warn allow okay,good;
>
> The attributes only issue warnings, so they wouldn't stop the code form
> compiling, and only when more smelly code is called.
>
>
> I hope that I have illustraded that user definded code attributes
> could be very useful.
>
> Knud

April 04, 2008
On Fri, Apr 4, 2008 at 7:19 AM, Knud Soerensen <4tuu4k002@sneakemail.com> wrote:
>
>  With all the talk about pure, safed and transitivity.
>  I think the time is right for a discussion about
>  user defined code attributes.
>
>  Code attributes is just meta data for the code.
>  Normally, this meta data is stored in revision systems, databases, in
>  the code comments or just plain left out.
>  But there is some advantages by placing them in the code and letting the
>  compiler take care of them.
>
>  Scott Meyers does a good job of introducing the subject in
>  http://video.google.com/videoplay?docid=-4728145737208991310
>
>  ----
>
>  The simplest use of code attribute I can imagine
>  is a attribute which indicate that this piece of code have been review.
>  It could be defined by.
>  attribute KilroyWasHere;

For all that I'd love to see something like .NET attributes in D, if it means people starting to mark functions and fields with [BugFix(1234)] or [ReviewedBy("me")] then count me out! Source files, i.e. the data structures you feed to a compiler,  really isn't the place for adding support for ticket tracking or a review process. :)

For the first case, get a revision control system and use its annotation function (this has the benefit of systematically recording all changes to every line of code in a file, not just ones some programmer arbitrarily decided to tag with an attribute). For the latter case, see something like review-board.org or search Google for "QA branch". These really aren't good uses of custom attributes at all.


David.
April 04, 2008
Janice Caron, el  4 de abril a las 08:42 me escribiste:
> On 04/04/2008, Knud Soerensen <4tuu4k002@sneakemail.com> wrote: <snip>
> 
> Nice. But to avoid accruing an infinite number of keywords, the syntax needs to be slightly changed. Instead of
> 
>     int func(param p1) KilroyWasHere
>     {
>         ...
>     }
> 
> use
> 
>     int func(param p1) attribute(KilroyWasHere)
>     {
>         ...
>     }

Or something simpler, like Python's decorators:

@KilroyWasHere
int func(param p1)
{
    ...
}

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
All men are born equal
But quite a few get over it
April 04, 2008
Leandro Lucarella:
> Or something simpler, like Python's decorators:
> @KilroyWasHere
> int func(param p1)
> {
>     ...
> }

Do you mean to copy just the syntax? Because Python decorator semantics is quite different, they are a way to feed a function/method to one of more metafunctions :-)

So this:

@foo
int func(param p1) {}

means something like:

func = foo(func)

And there are more complex usages, stacking more than one decorators, giving them arguments, etc.

Bye,
bearophile
April 05, 2008
Janice Caron wrote:
> On 04/04/2008, Knud Soerensen <4tuu4k002@sneakemail.com> wrote: <snip>
> 
> Nice. But to avoid accruing an infinite number of keywords, the syntax needs to be slightly changed. Instead of
> 
>     int func(param p1) KilroyWasHere
>     {
>         ...
>     }
> 
> use
> 
>     int func(param p1) attribute(KilroyWasHere)
>     {
>         ...
>     }

You could also ague that it is not necessary because attributes can only appear in certain places

only in function, class, struct and module declarations.
April 05, 2008
Leandro Lucarella wrote:
> Janice Caron, el  4 de abril a las 08:42 me escribiste:
>> On 04/04/2008, Knud Soerensen <4tuu4k002@sneakemail.com> wrote: <snip>
>>
>> Nice. But to avoid accruing an infinite number of keywords, the syntax needs to be slightly changed. Instead of
>>
>>     int func(param p1) KilroyWasHere
>>     {
>>         ...
>>     }
>>
>> use
>>
>>     int func(param p1) attribute(KilroyWasHere)
>>     {
>>         ...
>>     }
> 
> Or something simpler, like Python's decorators:
> 
> @KilroyWasHere
> int func(param p1)
> {
>     ...
> }

I like the idea with @ as short for (at)tribute.
April 05, 2008
On 05/04/2008, Knud Soerensen <4tuu4k002@sneakemail.com> wrote:
> You could also ague that it is not necessary because
>  attributes can only appear in certain places
>
>  only in function, class, struct and module declarations.

    KilroyWasHere:

Is that an attribute or a label?
April 05, 2008
Koroskin Denis wrote:
> Good, but I'd rather see 'thread-safe' built-in attribute.
> 
Yes, a threat-safe attribute would be very useful.

But if we can utilise the same code that help
implement build-in attributes like const, pure or thread-safe
to define user defined constrains
that would be a much better utilisation of the code and make D more
powerful.

> On Fri, 04 Apr 2008 11:19:49 +0400, Knud Soerensen <4tuu4k002@sneakemail.com> wrote:
> 
>>
>> With all the talk about pure, safed and transitivity.
>> I think the time is right for a discussion about
>> user defined code attributes.
>>
>> Code attributes is just meta data for the code.
>> Normally, this meta data is stored in revision systems, databases, in
>> the code comments or just plain left out.
>> But there is some advantages by placing them in the code and letting the
>> compiler take care of them.
>>
>> Scott Meyers does a good job of introducing the subject in http://video.google.com/videoplay?docid=-4728145737208991310
>>
>> ----
>>
>> The simplest use of code attribute I can imagine
>> is a attribute which indicate that this piece of code have been review.
>> It could be defined by.
>> attribute KilroyWasHere;
>>
>> and used like
>> int func(param p1) KilroyWasHere
>> {
>> ...
>> }
>>
>> You can do this with comments as well, but imagine you use.
>>
>> attribute FixMe warn;
>>
>> and the compile gave you a warning every time it sees the FixMe attribute.
>>
>> attribute FixMe fail;
>>
>> Would give you a error and the build would fail.
>>
>> ----
>>
>> The next attribute indicate that the code is license under the GPL.
>>
>> attribute GPL transitive;
>>
>> Here the transitive keyword tells the compiler that the attribute is transitive, and the compiler should check that every function called also has the attribute GPL.
>> ----
>>
>> attribute LGPL deny GPL;
>>
>> This attribute is not transitive but the code should not call GPL code.
>> -----
>>
>> attribute safe transitive allow pure;
>>
>> Define an attribute for thread-safety which is transitive but also allows pure functions. pure would be a build in attribute because it need to be able to validate the code.
>> -----
>>
>> Now imagine a big team need to refactor a big ugly code base.
>>
>> Then the following attributes will allow the team to mark the code after how it smells (good, okay or bad);
>>
>> attribute good transitive warn;
>> attribute okay transitive warn allow good;
>> attribute bad transitive warn allow okay,good;
>>
>> The attributes only issue warnings, so they wouldn't stop the code form compiling, and only when more smelly code is called.
>>
>>
>> I hope that I have illustraded that user definded code attributes could be very useful.
>>
>> Knud
> 
« First   ‹ Prev
1 2