On Wed, Apr 11, 2012 at 2:55 AM, RonJeffries <ronjeffries@...> wrote:

> **
>
>
> Hi Theresa,
>
>
> On Apr 11, 2012, at 4:30 AM, Theresa Forster wrote:
>
> > My first thought was to create a repo layer with entities mapped to the
> > "tables" in the dataset. And then drive out the functionality required,
>
> That's pretty much what I'd do.
>


I sense miscommunication here.

It appears that Theresa is saying is to start by implementing objects that
map to and from all the existing data.

What I would both do is to not start from the existing data, but rather to
end there.  I would start from the business functionality required for the
current user story, and implement it top-down from what the GUI (or web
service) needs to the objects that most appropriately serve the user story
and model the business domain.  *Only* at the bottom of that chain would I
worry about how those object retrieve and store data in the fixed database.
  I would think that Ron and others would basically agree.

Most of the time, how to mediate the data objects that the business objects
need with a fixed schema is fairly easy.  When it is not, I would rather
keep all that mess in the data objects than let that mess screw up all my
code.

And I would only worry about the current user story.  Then next user story
would proceed the same way, but would always be looking for ways to
refactor the code for that story and the code for previous stories to
maximize reuse and better express what we have since learned about the
business domain.

Steven Gordon


> And I'd chat about it with other members of my Agile team.
>
>
> Ron Jeffries
> www.XProgramming.com
> If it is more than you need, it is waste. -- Andy Seidl
>
>
>


[Non-text portions of this message have been removed]

Hi Laurent,

On Apr 11, 2012, at 11:35 AM, Laurent Bossavit wrote:

> Annotations. It's what they're for.
>
> Prior art, easily Googled:
>  http://www.jpatterns.org/
>  http://code.google.com/p/patternnotes/
>  http://jpp.sourceforge.net/
>
Nice, cool, thanks.

> Here's a thought, though. You don't promote code understanding by *adding*
more elements to keep track of, increasing cognitive load. You promote code
understanding by *removing* elements - through psychological mechanism such as
chunking or principle of least astonishment.

Agreed, quite fully.
>
> Attempts to promote code understanding that focus exclusively on the code, and
exclude from consideration the humain brains doing the understanding, are bound
to fail.


Precisely.

Ron Jeffries
www.XProgramming.com
Wisdom begins when we understand the difference between "that makes no sense"
and "I don't understand". -- Mary Doria Russell



[Non-text portions of this message have been removed]

Hey, Laurent,

Is there a C# equivalent?  Attributes?

Kay Pentecost


> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Laurent Bossavit
> Sent: Wednesday, April 11, 2012 11:35 AM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] indicating pattern in Java code
>
> > If you did want to indicate the patterns involved in your code, what
> would you do?
>
> Annotations. It's what they're for.
>
> Prior art, easily Googled:
>   http://www.jpatterns.org/
>   http://code.google.com/p/patternnotes/
>   http://jpp.sourceforge.net/
>
> Here's a thought, though. You don't promote code understanding by *adding*
> more elements to keep track of, increasing cognitive load. You promote
> code understanding by *removing* elements - through psychological
> mechanism such as chunking or principle of least astonishment.
>
> Attempts to promote code understanding that focus exclusively on the code,
> and exclude from consideration the humain brains doing the understanding,
> are bound to fail.
>
> Cheers,
> Laurent
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to: extremeprogramming-
> unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>

Hi Kay,

Having attributes that actually create the code for a particular pattern
seems like a
cool thing, but it might be a mixed blessing.

The good side is that it guarantees all implementations work the same. The
bad
side is that it guarantees all implementations work the same.

Charlie

On Wed, Apr 11, 2012 at 12:16 PM, Kay A Pentecost
<tranzpupy@...>wrote:

> **
>
>
> Hey, Laurent,
>
> Is there a C# equivalent? Attributes?
>
> Kay Pentecost
>
> > -----Original Message-----
> > From: extremeprogramming@yahoogroups.com
> > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Laurent
> Bossavit
> > Sent: Wednesday, April 11, 2012 11:35 AM
> > To: extremeprogramming@yahoogroups.com
> > Subject: Re: [XP] indicating pattern in Java code
> >
> > > If you did want to indicate the patterns involved in your code, what
> > would you do?
> >
> > Annotations. It's what they're for.
> >
> > Prior art, easily Googled:
> > http://www.jpatterns.org/
> > http://code.google.com/p/patternnotes/
> > http://jpp.sourceforge.net/
> >
> > Here's a thought, though. You don't promote code understanding by
> *adding*
> > more elements to keep track of, increasing cognitive load. You promote
> > code understanding by *removing* elements - through psychological
> > mechanism such as chunking or principle of least astonishment.
> >
> > Attempts to promote code understanding that focus exclusively on the
> code,
> > and exclude from consideration the humain brains doing the understanding,
> > are bound to fail.
> >
> > Cheers,
> > Laurent
> >
> >
> >
> > ------------------------------------
> >
> > To Post a message, send it to: extremeprogramming@eGroups.com
> >
> > To Unsubscribe, send a blank message to: extremeprogramming-
> > unsubscribe@eGroups.com
> >
> > ad-free courtesy of objectmentor.comYahoo! Groups Links
> >
> >
> >
>
>


[Non-text portions of this message have been removed]

Hi, Charlie!

Embedded below:


> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Charlie Poole
> Sent: Wednesday, April 11, 2012 3:48 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] indicating pattern in Java code
>
> Hi Kay,
>
> Having attributes that actually create the code for a particular pattern
> seems like a
> cool thing, but it might be a mixed blessing.

Please excuse my ignorance, but do Java annotations create code? I don't
know exactly *how* attributes work, although I use them -- certainly when I
use NUnit.  And I use NUnit whenever I create code...

>
> The good side is that it guarantees all implementations work the same. The
> bad
> side is that it guarantees all implementations work the same.

Now that I *completely* understand.  A conundrum, right?

Thanks,

Kay Pentecost

>> -----Original Message-----
>> From: Charlie Poole
>> Having attributes that actually create the code for a particular
>> pattern seems like a cool thing, but it might be a mixed blessing.

--- "Kay A Pentecost" <tranzpupy@...> wrote:
> Please excuse my ignorance, but do Java annotations create code?
> I don't know exactly *how* attributes work, although I use them
> -- certainly when I use NUnit.  And I use NUnit whenever I create
> code...

Old answer:  No.
New answer:  Yes.

It's a common misunderstanding to assume that annotations generate code. 
Typically, they do not.  It used to be that there was no way they could.  But
with recent Java compiler extensions, annotations can be used to change the code
that is generated.

In traditional usage, as with NUnit, annotations are passive:  They are
available as data at run time, accessible through the reflection API.  But the
annotations themselves don't "do" anything.  Strictly speaking, they have no
behavior; they only hold data, and make it available to code that looks for
them.  But the code that looks for them can do things, giving the appearance
that annotations *DO* something.

Clear as mud?
(If so, then my work here is done!   ;-)

Hi Kay,> Having attributes that actually create the code for a particular
pattern

> > seems like a
> > cool thing, but it might be a mixed blessing.
>
> Please excuse my ignorance, but do Java annotations create code? I don't
> know exactly *how* attributes work, although I use them -- certainly when I
> use NUnit. And I use NUnit whenever I create code...
>

The references indicate that code is generated from these particular
annotations.

Attributes don't actually create code but can be used by the compiler or a
pre-processor as a signal to generate code. Somebody could create such a
compiler extension to recognize attributes representing various patterns.
It's not a trivial thing, obviously.


> >
> > The good side is that it guarantees all implementations work the same.
> The
> > bad
> > side is that it guarantees all implementations work the same.
>
> Now that I *completely* understand. A conundrum, right?
>

Glad I could clear that up. ;-)

Charlie


>
> Thanks,
>
> Kay Pentecost
>
>
>


[Non-text portions of this message have been removed]

Hi Jeff,

In traditional usage, as with NUnit, annotations are passive: They are
> available as data at run time, accessible through the reflection API. But
> the annotations themselves don't "do" anything. Strictly speaking, they
> have no behavior; they only hold data, and make it available to code that
> looks for them. But the code that looks for them can do things, giving the
> appearance that annotations *DO* something.
>
>
FWIW, NUnit 2.x annotations are _mostly_ passive. In NUnit 3.0, they are
mostly active.

Charlie


[Non-text portions of this message have been removed]

Thanks George.

P.

--- In extremeprogramming@yahoogroups.com, George Dinwiddie <lists@...> wrote:
>
> Paul,
>
> On 4/11/12 2:14 AM, PAUL wrote:
> >
> >
> >
> > Hi All,
> >
> > Thanks for sharing. Nice to know that I haven't been living in some
> > parallel universe:)  Given that this scenario is widespread I've been
> > experimenting with doing more then just walking away (been there done
> > that).
> >
> > I've been using the Satir Change model :
> >
> > http://stevenmsmith.com/ar-satir-change-model/
> >
> > Baring in mind that agile is the "foreign element", if the resistance
> > to change and the fear of "chaos" proves too much, what you can do is
> > have another go, but only this time be "less foreign", presenting the
> > organisation with a smaller step change.
>
> As you look at that model, consider that each person finds a
> transforming idea (or several) individually and separately. As change
> gets assimilated, you'll notice that the atmosphere of the organization
> changes, and that helps others find their transforming idea. Change
> happens one person at a time.
>
> I'd also suggest reading Dale Emery's material on "Resistance as a
> Resource." I've found that Dale is generally right, and that people are
> not, in general, resistors, but they want to hold onto something that
> they value. It's helpful to understand what that is.
>
>   - George
>
> --
>   ----------------------------------------------------------------------
>    * George Dinwiddie *                      http://blog.gdinwiddie.com
>    Software Development                    http://www.idiacomputing.com
>    Consultant and Coach                    http://www.agilemaryland.org
>   ----------------------------------------------------------------------
>

Oh, Wow, Charlie,

> FWIW, NUnit 2.x annotations are _mostly_ passive. In NUnit 3.0, they are
> mostly active.

Could you give an (English or PseudoCode) example of an active attribute?

Also, I couldn't find a release or source code for NUnit 3.0... Is one
available?

Thanks,

Kay Pentecost


> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Charlie Poole
> Sent: Wednesday, April 11, 2012 4:19 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] indicating pattern in Java code
>
> Hi Jeff,
>
> In traditional usage, as with NUnit, annotations are passive: They are
> > available as data at run time, accessible through the reflection API.
> But
> > the annotations themselves don't "do" anything. Strictly speaking, they
> > have no behavior; they only hold data, and make it available to code
> that
> > looks for them. But the code that looks for them can do things, giving
> the
> > appearance that annotations *DO* something.
> >
> >
> FWIW, NUnit 2.x annotations are _mostly_ passive. In NUnit 3.0, they are
> mostly active.
>
> Charlie
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to: extremeprogramming-
> unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>

Hey, Charlie,



> -----Original Message-----
<snip>
>
> The references indicate that code is generated from these particular
> annotations.

And I'm getting the feeling that code isn't actually generated from *all*
annotations.

>
> Attributes don't actually create code but can be used by the compiler or a
> pre-processor as a signal to generate code. Somebody could create such a
> compiler extension to recognize attributes representing various patterns.
> It's not a trivial thing, obviously.

So it's possible that the referenced annotations do create code, and you're
saying that they could create code by writing code that makes the compiler
or pre-processor create the code that makes a annotation appear to "create
code."  ??  Hmmmm.

>
>
> > >
> > > The good side is that it guarantees all implementations work the same.
> > The
> > > bad
> > > side is that it guarantees all implementations work the same.
> >
> > Now that I *completely* understand. A conundrum, right?
> >
>
> Glad I could clear that up. ;-)

I am too.

Thanks,

Kay Pentecost

Hey, Jeff!

Clear as mud?  What you wrote is totally understandable, and actually fits
with what I thought I knew about attributes.

Also tells me I need to learn more... yet again...

Thanks!!

Kay Pentecost

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of JeffGrigg
> Sent: Wednesday, April 11, 2012 4:12 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] indicating pattern in Java code
>
> >> -----Original Message-----
> >> From: Charlie Poole
> >> Having attributes that actually create the code for a particular
> >> pattern seems like a cool thing, but it might be a mixed blessing.
>
> --- "Kay A Pentecost" <tranzpupy@...> wrote:
> > Please excuse my ignorance, but do Java annotations create code?
> > I don't know exactly *how* attributes work, although I use them
> > -- certainly when I use NUnit.  And I use NUnit whenever I create
> > code...
>
> Old answer:  No.
> New answer:  Yes.
>
> It's a common misunderstanding to assume that annotations generate code.
> Typically, they do not.  It used to be that there was no way they could.
> But with recent Java compiler extensions, annotations can be used to
> change the code that is generated.
>
> In traditional usage, as with NUnit, annotations are passive:  They are
> available as data at run time, accessible through the reflection API.  But
> the annotations themselves don't "do" anything.  Strictly speaking, they
> have no behavior; they only hold data, and make it available to code that
> looks for them.  But the code that looks for them can do things, giving
> the appearance that annotations *DO* something.
>
> Clear as mud?
> (If so, then my work here is done!   ;-)
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to: extremeprogramming-
> unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>

Looks like NUnit 3.0 is under development, and can be seen as "2.9" milestone
releases.

http://nunit.org/wiki/doku.php?id=dev:roadmap#nunit_30

Looks like "Active Attributes" are a plan for the code that reads the attributes
to delegate control to them, rather than just acting on the data in passive
objects.  [That sounds like a good idea!  ;-) ]

http://nunit.org/wiki/doku.php?id=dev:specs:active_attributes#active_attributes1


--- "Kay A Pentecost" <tranzpupy@...> wrote:
>
> Oh, Wow, Charlie,
>
>> FWIW, NUnit 2.x annotations are _mostly_ passive. In NUnit 3.0,
>> they are mostly active.
>
> Could you give an (English or PseudoCode) example of an active
> attribute?
>
> Also, I couldn't find a release or source code for NUnit 3.0...
> Is one available?
>
> Thanks,
>
> Kay Pentecost

--- "Kay A Pentecost" <tranzpupy@...> wrote:
> So it's possible that the referenced annotations do create code,
> and you're saying that they could create code by writing code
> that makes the compiler or pre-processor create the code that
> makes a annotation appear to "create code."  ??  Hmmmm.

Do JavaDoc annotations generate code?
No, but you can write a program that reads the JavaDoc comments and generates
data, reports, code, and other things.

Does the Java source code 'if (f(3)) System.out.println("Hello!");' generate
code?
Well, no; we don't normally think of it that way.  Sometimes we do, but
generally we say that the Java compiler reads the Java source code and generates
(byte) code from it.

Do Java or .Net annotations generate code or execute?
No.  They are passive data holders.  They are typically Anemic
(http://en.wikipedia.org/wiki/Anemic_domain_model).

But wait...
Annotations are implemented in Java and .Net by creating special classes. 
Instances of those classes are instantiated at run time to hold the annotation
data.  You can fetch those instances through the reflection API.

So...
You *have* instances of classes that you wrote.  You could put methods on those
classes too.  And you could call those methods, once you fetched the instance,
using reflection.  That would be pretty "object oriented" and non-anemic.

Most people don't do that.  But you could.  Looks like they are doing it in
NUnit 2.9/3.0.

--- "JeffGrigg" <jeffreytoddgrigg@...> wrote:
> Do Java or .Net annotations generate code or execute?
> No.  They are passive data holders.  They are typically
>   Anemic (http://en.wikipedia.org/wiki/Anemic_domain_model).

P.S. I was also going to say...
Java and .Net do not have any standard platform or language-specified "execution
model" for calling annotation class methods at compile or run time.

Hi Kay,

And I'm getting the feeling that code isn't actually generated from *all*
> annotations.
>
> No, definitely not. An annotation is just an annotation. Somebody has to
read
it and decide to do something with it. The JUnit runner decides to run tests
based on annotations. The code that recognizes the particular pattern
annotations
that Laurent referenced generates code based on those annotations.

> >
> > Attributes don't actually create code but can be used by the compiler or
> a
> > pre-processor as a signal to generate code. Somebody could create such a
> > compiler extension to recognize attributes representing various patterns.
> > It's not a trivial thing, obviously.
>
> So it's possible that the referenced annotations do create code, and you're
> saying that they could create code by writing code that makes the compiler
> or pre-processor create the code that makes a annotation appear to "create
> code." ?? Hmmmm.
>

Well, I only know that they do because I read the linked articles, since I
know
almost nothing abuot Java annotations. That's why I was changing the subject
to .NET attributes, which I do understand.

That said, I believe the correct phrasing would be that the referenced
annotations
are recognized by some compiler extension, which then creates code.

Attributes in .NET are "kind of like" annotations, but that's all. For one
thing,
they are first class objects and can have methods, properties, etc.,
although
somebody has to call that code before it can do anything. I'm not sure if
Java
Annotations are first class objects - some Java guy can tell us I'm sure.

Charlie

>
> >
> >
> > > >
> > > > The good side is that it guarantees all implementations work the
> same.
> > > The
> > > > bad
> > > > side is that it guarantees all implementations work the same.
> > >
> > > Now that I *completely* understand. A conundrum, right?
> > >
> >
> > Glad I could clear that up. ;-)
>
> I am too.
>
> Thanks,
>
> Kay Pentecost
>
>
>


[Non-text portions of this message have been removed]

Hi Kay,

Getting OT for XP, but we're not the first to do that!

On Wed, Apr 11, 2012 at 1:42 PM, Kay A Pentecost <tranzpupy@...>wrote:

> **
>
>
> Oh, Wow, Charlie,
>
> > FWIW, NUnit 2.x annotations are _mostly_ passive. In NUnit 3.0, they are
> > mostly active.
>
> Could you give an (English or PseudoCode) example of an active attribute?
>
> For example, an IgnoreAttribute (NUnit) implements IApplyToTest, with a
single
method ApplyToTest(Test test). When called, the attribute marks that test
as ignored.

That way, the calling code doesn't need to know what the attribute does,
only that
it modifies a test in some way. It can then handle all attributes
implementing that
attribute in the same way and new attributes of that type can be created at
will.

Also, I couldn't find a release or source code for NUnit 3.0... Is one
> available?
>

Look at http://launchpad.net/nunit-3.0

Charlie

> Thanks,
>
>
> Kay Pentecost
>
> > -----Original Message-----
> > From: extremeprogramming@yahoogroups.com
> > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Charlie Poole
> > Sent: Wednesday, April 11, 2012 4:19 PM
> > To: extremeprogramming@yahoogroups.com
> > Subject: Re: [XP] indicating pattern in Java code
> >
> > Hi Jeff,
>
> >
> > In traditional usage, as with NUnit, annotations are passive: They are
> > > available as data at run time, accessible through the reflection API.
> > But
> > > the annotations themselves don't "do" anything. Strictly speaking, they
> > > have no behavior; they only hold data, and make it available to code
> > that
> > > looks for them. But the code that looks for them can do things, giving
> > the
> > > appearance that annotations *DO* something.
> > >
> > >
> > FWIW, NUnit 2.x annotations are _mostly_ passive. In NUnit 3.0, they are
> > mostly active.
> >
> > Charlie
> >
> >
> > [Non-text portions of this message have been removed]
>
> >
> >
> >
> > ------------------------------------
> >
> > To Post a message, send it to: extremeprogramming@eGroups.com
> >
> > To Unsubscribe, send a blank message to: extremeprogramming-
> > unsubscribe@eGroups.com
> >
> > ad-free courtesy of objectmentor.comYahoo! Groups Links
> >
> >
> >
>
>
>


[Non-text portions of this message have been removed]

> Do Java or .Net annotations generate code or execute?
> No. They are passive data holders. They are typically Anemic
(http://en.wikipedia.org/wiki/Anemic_domain_model).
>
> But wait...
> Annotations are implemented in Java and .Net by creating special classes.
Instances of those classes are instantiated at run time to hold the annotation
data. You can fetch those instances through the reflection API.

Ah ha! I read somewhere that Java annotations could not be used this
way. Seems like that was wrong. It's not surprising since most people
don't think about C# attributes in that way either, even though it's
quite possible.

> So...
> You *have* instances of classes that you wrote. You could put methods on those
classes too. And you could call those methods, once you fetched the instance,
using reflection. That would be pretty "object oriented" and non-anemic.

It's probably overkill in a lot of cases, but if you want to create an
extensible attribute-driven framework...

> Most people don't do that. But you could. Looks like they are doing it in
NUnit 2.9/3.0.

Actually, I first saw the notion of active attributes used in mbUnit,
a long while back. At the time it seemed like overkill but now... :-)

Charlie

>

Ron,

On 4/11/12 10:03 AM, RonJeffries wrote:
> If I was using some corporate pattern from my SLE, say
> BusinessSupervisor pattern, I think that rather than name my Manager
> class:
>
> 	 ManagerBS
>
> I would be more inclined to indicate the fact by implementing an
> interface BusinessSupervisor and saying in my class declaration
> something like:
>
> 	 class Manager implements BusinessSupervisor

I like that better, but I don't think I've done that without having some
method declared in the interface.

> If you did want to indicate the patterns involved in your code, what
> would you do?

As I think about it more, I'm likely to reverse the pattern you used
above.  I'd be more likely to say

	 class BusinessSupervisor implements Manager

so the client code only has to know about Manager, not the
implementation. Or, I might do something like

	 class OracleFooDAO implements FooPersistence

which is similar to what Marvin suggests, except that outside of the
implementing class, the only entities that need to know the implementing
name is the factory, dependency injection, or service locator that is
providing a FooPersistence object. The rest of my domain logic would
only know about FooPersistence.

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

> --- Jeff Grigg wrote:
>> Annotations are implemented in Java and .Net by creating
>> special classes. ...

--- Charlie Poole <charliepoole@...> wrote:
> Ah ha! I read somewhere that Java annotations could not be used
> this way. Seems like that was wrong. ...

Oops! Sorry; I was thinking Gosu.

Java annotations are interfaces, not classes.  So I guess they're right about
the limitations.

So I guess I was wrong.  :-(

Hey, Charlie,

Thanks for all this.  It gives me a good start at learning about this, and
trying it out somewhere.

Kay Pentecost

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Charlie Poole
> Sent: Wednesday, April 11, 2012 7:50 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] indicating pattern in Java code
>
> Hi Kay,
>
> And I'm getting the feeling that code isn't actually generated from *all*
> > annotations.
> >
> > No, definitely not. An annotation is just an annotation. Somebody has to
> read
> it and decide to do something with it. The JUnit runner decides to run
> tests
> based on annotations. The code that recognizes the particular pattern
> annotations
> that Laurent referenced generates code based on those annotations.
>
> > >
> > > Attributes don't actually create code but can be used by the compiler
> or
> > a
> > > pre-processor as a signal to generate code. Somebody could create such
> a
> > > compiler extension to recognize attributes representing various
> patterns.
> > > It's not a trivial thing, obviously.
> >
> > So it's possible that the referenced annotations do create code, and
> you're
> > saying that they could create code by writing code that makes the
> compiler
> > or pre-processor create the code that makes a annotation appear to
> "create
> > code." ?? Hmmmm.
> >
>
> Well, I only know that they do because I read the linked articles, since I
> know
> almost nothing abuot Java annotations. That's why I was changing the
> subject
> to .NET attributes, which I do understand.
>
> That said, I believe the correct phrasing would be that the referenced
> annotations
> are recognized by some compiler extension, which then creates code.
>
> Attributes in .NET are "kind of like" annotations, but that's all. For one
> thing,
> they are first class objects and can have methods, properties, etc.,
> although
> somebody has to call that code before it can do anything. I'm not sure if
> Java
> Annotations are first class objects - some Java guy can tell us I'm sure.
>
> Charlie
>

Hey Charlie,



> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Charlie Poole
> Sent: Wednesday, April 11, 2012 7:57 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] indicating pattern in Java code
>
> Hi Kay,
>
> Getting OT for XP, but we're not the first to do that!

Sorry about that. <grin>

Maybe I should have started by saying "When you're trying to get started
with pair programming, how do you use attributes in an active way..."
<giggle>


>
> On Wed, Apr 11, 2012 at 1:42 PM, Kay A Pentecost
> <tranzpupy@...>wrote:
>
> > **
> >
> >
> > Oh, Wow, Charlie,
> >
> > > FWIW, NUnit 2.x annotations are _mostly_ passive. In NUnit 3.0, they
> are
> > > mostly active.
> >
> > Could you give an (English or PseudoCode) example of an active
> attribute?
> >
> > For example, an IgnoreAttribute (NUnit) implements IApplyToTest, with a
> single
> method ApplyToTest(Test test). When called, the attribute marks that test
> as ignored.
>
> That way, the calling code doesn't need to know what the attribute does,
> only that
> it modifies a test in some way. It can then handle all attributes
> implementing that
> attribute in the same way and new attributes of that type can be created
> at
> will.

I think I understand that.  Thank you!
>
> Also, I couldn't find a release or source code for NUnit 3.0... Is one
> > available?
> >
>
> Look at http://launchpad.net/nunit-3.0

Oh, Thanks.

Kay Pentecost

Hi, Jeff,

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of JeffGrigg
> Sent: Wednesday, April 11, 2012 7:05 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] indicating pattern in Java code
>
> --- "Kay A Pentecost" <tranzpupy@...> wrote:
> > So it's possible that the referenced annotations do create code,
> > and you're saying that they could create code by writing code
> > that makes the compiler or pre-processor create the code that
> > makes a annotation appear to "create code."  ??  Hmmmm.
>
> Do JavaDoc annotations generate code?
> No, but you can write a program that reads the JavaDoc comments and
> generates data, reports, code, and other things.

I've never thought of JavaDoc as generating code...

>
> Does the Java source code 'if (f(3)) System.out.println("Hello!");'
> generate code?
> Well, no; we don't normally think of it that way.  Sometimes we do, but
> generally we say that the Java compiler reads the Java source code and
> generates (byte) code from it.

Yes, the compiler (Java or C#) creates (byte) code from the source code...

>
> Do Java or .Net annotations generate code or execute?
> No.  They are passive data holders.  They are typically Anemic
> (http://en.wikipedia.org/wiki/Anemic_domain_model).
>
> But wait...
> Annotations are implemented in Java and .Net by creating special classes.
> Instances of those classes are instantiated at run time to hold the
> annotation data.  You can fetch those instances through the reflection
> API.
>
> So...
> You *have* instances of classes that you wrote.  You could put methods on
> those classes too.  And you could call those methods, once you fetched the
> instance, using reflection.  That would be pretty "object oriented" and
> non-anemic.

That's interesting.  I'd like to see examples of that... in C#.

>
> Most people don't do that.  But you could.  Looks like they are doing it
> in NUnit 2.9/3.0.

I'm looking forward to see what that looks like.

Thanks,

Kay Pentecost

Hi

You can use annotations in Java to generate code. JDK 1.5 had an experimental
API for this that required a tool called APT that was separate from the java
compiler (javac). Since JDK 1.6, annotation processing has been fully embedded
in javac.

The Jedi library makes extensive use of this: http://jedi.codehaus.org/

But it's better just to use a proper language.

Regards,

Lance

--- In extremeprogramming@yahoogroups.com, "Kay A Pentecost" <tranzpupy@...>
wrote:
>
> Please excuse my ignorance, but do Java annotations create code?

Hi folks,

Quick question on nomenclature.

I currently prefer to count stories per iteration rather than estimating points
per card.

I've continued to call the number of stories completed in an iteration velocity
(my logic being that it's just the degenerate case of story point estimating
where each card has one point).

In conversation recently I confused somebody by doing this. They view story
counting as a different "kind" of process from estimating with points, and only
use "velocity" in the latter context. I can understand their point of view, but
this is the first time I've come across this particular cause of confusion.

Since, generally, I try not to confuse people when I talk - I'd be interested to
know if this is a commonly held viewpoint.

Okay to use "velocity" to describe stories per iteration; Yay or nay?

Curiously,

Adrian
--
http://quietstars.com     adrianh@...     twitter.com/adrianh
t. +44 (0)7752 419080     skype adrianjohnhoward     del.icio.us/adrianh

It's valid if you keep your stories to more or less the same size (making
SP meaningless).

--
Peter Scheyen, CTO, Richard Ivey School of Business
Twitter: @pscheyen

On 2012-04-12, at 1:33 PM, Adrian Howard <adrianh@...> wrote:



Hi folks,

Quick question on nomenclature.

I currently prefer to count stories per iteration rather than estimating
points per card.

I've continued to call the number of stories completed in an iteration
velocity (my logic being that it's just the degenerate case of story point
estimating where each card has one point).

In conversation recently I confused somebody by doing this. They view story
counting as a different "kind" of process from estimating with points, and
only use "velocity" in the latter context. I can understand their point of
view, but this is the first time I've come across this particular cause of
confusion.

Since, generally, I try not to confuse people when I talk - I'd be
interested to know if this is a commonly held viewpoint.

Okay to use "velocity" to describe stories per iteration; Yay or nay?

Curiously,

Adrian
--
http://quietstars.com adrianh@... twitter.com/adrianh
t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh




[Non-text portions of this message have been removed]

On 12 Apr 2012, at 18:35, Peter Scheyen wrote:

> It's valid if you keep your stories to more or less the same size (making
> SP meaningless).

I'm not worried about whether it works or not (happy to argue that if folk want
of course :-)

It's just whether using the word "velocity" is likely to confuse some folk.

Cheers,

Adrian
--
http://quietstars.com     adrianh@...     twitter.com/adrianh
t. +44 (0)7752 419080     skype adrianjohnhoward     del.icio.us/adrianh

Hi Adrian,

On Apr 12, 2012, at 1:33 PM, Adrian Howard wrote:

> Okay to use "velocity" to describe stories per iteration; Yay or nay?


As far as I know, I invented both ways, and I say it is OK. :)

Ron Jeffries
www.XProgramming.com
Sometimes I give myself admirable advice, but I am incapable of taking it.
-- Mary Wortley Montagu





[Non-text portions of this message have been removed]

Hi Ron,

On 12 Apr 2012, at 18:38, RonJeffries wrote:

> On Apr 12, 2012, at 1:33 PM, Adrian Howard wrote:
>
>> Okay to use "velocity" to describe stories per iteration; Yay or nay?
>
> As far as I know, I invented both ways, and I say it is OK. :)


I am reassured :-)

Cheers,

Adrian
--
http://quietstars.com     adrianh@...     twitter.com/adrianh
t. +44 (0)7752 419080     skype adrianjohnhoward     del.icio.us/adrianh

Thank you, Lance!

Kay Pentecost

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of extremeprogrammer
> Sent: Thursday, April 12, 2012 9:25 AM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] indicating pattern in Java code
>
> Hi
>
> You can use annotations in Java to generate code.