Thread overview | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 04, 2008 pure, safe and generalized attributes | ||||
---|---|---|---|---|
| ||||
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 Re: pure, safe and generalized attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Knud Soerensen | 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 Re: pure, safe and generalized attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Knud Soerensen | 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 Re: pure, safe and generalized attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Knud Soerensen | 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 Re: pure, safe and generalized attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Janice Caron | 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 Re: pure, safe and generalized attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Leandro Lucarella | 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 Re: pure, safe and generalized attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Janice Caron | 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 Re: pure, safe and generalized attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Leandro Lucarella | 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 Re: pure, safe and generalized attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Knud Soerensen | 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 Re: pure, safe and generalized attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Koroskin Denis | 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 > |
Copyright © 1999-2021 by the D Language Foundation