AspectJ: solution to Java's repetitiveness?

java-programmer, AspectJ: solution to Java's repetitiveness? thufir wrote:
> On Sat, 26 Apr 2008 06:51:43 -0400, Lew wrote:
>
>>> attrib_writer :foo, :bar #getter and setter for foo and bar attributes,
>>> #getter setter methods aren't actually written
>> Well, Java cannot do that because it's not in the language definition
>> and because the colon character already serves three other purposes in
>> Java.
>
> That Ruby syntax doesn't work in Java isn't the point at all.
>
>> I would just go with getters/setters. What's the big deal? My IDEs
>> generate them for me, so there's no typing, and it sure helps
>> maintainers to see them.
>>
>> It would be a huge waste of energy to retrofit Java with such a feature.
>
> The point is that getter/setter methods are boilerplate. Adding such a
> feature to Java would be worth it, and Java is constantly in flux.
>
>
> -Thufir

Can't you just add a (custom) annotation, e.g. "@JavaBean", and use
apt to generate the getters/setters? (Or possibly the newer
javax.annotation* stuff?) You could add options to such an
annotation e.g., read-only.
Then add the one extra line in your ant script to build code.

Note JavaEE defines many such annotations, including for an
MX Bean. Adding a standard annotation "@JavaBean" doesn't seem
like it would be that much effort, for a large convenience payoff.

<waffle>
Like Lew I use an IDE that does that for me. Still, I don't like
dependencies on particular tools that provide special features, if
the language could easily support them with little effort.

OTOH as others have pointed out in previous threads, the JavaBean
spec is rarely used, so maybe adding more standard annotations
isn't worth it.

If the OP thinks it should be used, create or modify a JSR for this
feature; if enough others agree it will be added.
</waffle>

-Wayne

java-programmer >> AspectJ: solution to Java's repetitiveness? thufir wrote:
> On Sat, 26 Apr 2008 06:51:43 -0400, Lew wrote:
>
>>> attrib_writer :foo, :bar #getter and setter for foo and bar attributes,
>>> #getter setter methods aren't actually written
>> Well, Java cannot do that because it's not in the language definition
>> and because the colon character already serves three other purposes in
>> Java.
>
> That Ruby syntax doesn't work in Java isn't the point at all.
>
>> I would just go with getters/setters. What's the big deal? My IDEs
>> generate them for me, so there's no typing, and it sure helps
>> maintainers to see them.
>>
>> It would be a huge waste of energy to retrofit Java with such a feature.
>
> The point is that getter/setter methods are boilerplate. Adding such a
> feature to Java would be worth it, and Java is constantly in flux.
>
>
> -Thufir

Can't you just add a (custom) annotation, e.g. "@JavaBean", and use
apt to generate the getters/setters? (Or possibly the newer
javax.annotation* stuff?) You could add options to such an
annotation e.g., read-only.
Then add the one extra line in your ant script to build code.

Note JavaEE defines many such annotations, including for an
MX Bean. Adding a standard annotation "@JavaBean" doesn't seem
like it would be that much effort, for a large convenience payoff.

<waffle>
Like Lew I use an IDE that does that for me. Still, I don't like
dependencies on particular tools that provide special features, if
the language could easily support them with little effort.

OTOH as others have pointed out in previous threads, the JavaBean
spec is rarely used, so maybe adding more standard annotations
isn't worth it.

If the OP thinks it should be used, create or modify a JSR for this
feature; if enough others agree it will be added.
</waffle>

-Wayne

java-programmer >> AspectJ: solution to Java's repetitiveness? Wayne wrote:

> Can't you just add a (custom) annotation, e.g. "@JavaBean", and use
> apt to generate the getters/setters? (Or possibly the newer
> javax.annotation* stuff?) You could add options to such an
> annotation e.g., read-only.
> Then add the one extra line in your ant script to build code.
>
> Note JavaEE defines many such annotations, including for an
> MX Bean. Adding a standard annotation "@JavaBean" doesn't seem
> like it would be that much effort, for a large convenience payoff.

It's also extra linguistic, which might help to keep the language small
while at the same time preserving readability. It's not one or two
getters/setters that the issue. It's when a class has twenty or thirty
that it starts to impinge on readability.

For more flexibility, something like this (syntax totally invented):

import javax.some.annotaion.framework.*;

public class PlentyAttributes {

private final static int SOME_CONST = 2;

private String internalValue;

@AttribReadOnly
{
private String value1;
private String value2;
private String value3;
private String value4;
}

@AttribMutator // = getter + setter
{
private String valueA;
private String valueB;
private String valueC;
private String valueD;
private String valueE;
private String valueF;
}

@AttribWriteOnly
{
private String valueX;
}

}

I think something like this, with braces to group fields, would improve
readability of classes with large numbers of properties, and also not
require any modifications to the core language. It could be stuffed in
a framework and left for the folks who think it would be useful.

java-programmer >> AspectJ: solution to Java's repetitiveness? mv discussion comp.lang.scheme

On Apr 26, 6:27 am, email***@***.com (Stefan Ram) wrote:

> For example, in Lisp, one can write macros for reoccuring
> idioms, but anyone who wants to read a program using them has
> to learn these macros first (or at least, when he is reading a
> usage of one of these macros).

The answer to this old argument is that this is no different from
procedures.

java-programmer >> AspectJ: solution to Java's repetitiveness? "email***@***.com" <email***@***.com> writes:
>>For example, in Lisp, one can write macros for reoccuring
>>idioms, but anyone who wants to read a program using them has
>>to learn these macros first (or at least, when he is reading a
>>usage of one of these macros).
>The answer to this old argument is that this is no different from
>procedures.

In most programming languages, parameters of procedures are
strict (they are evaluated at the time of the call). This
gives the reader of an invocation of a procedure some basic
information that is always valid. (In languages with
call-by-value only, one even can deduce that a call will never
alter an argument variable.)

Macros might have lazy parameters (they do not need to
evaluate all of their arguments), which opens more
possibilities for the interpretation of a macro call than for
the interpretation of a procedure name - even in the presence
of a good mnemonic macro name. They also might modify an
argument variable or do other things procedures can't do
and are overall more powerful than procedure calls.

(In languages with more syntax than Lisp, macros or language
extensions also might add additional syntax, which also makes
reading them more difficult.)

java-programmer >> AspectJ: solution to Java's repetitiveness? email***@***.com wrote:
> mv discussion comp.lang.scheme
>
> On Apr 26, 6:27 am, email***@***.com (Stefan Ram) wrote:
>
>> For example, in Lisp, one can write macros for reoccuring
>> idioms, but anyone who wants to read a program using them has
>> to learn these macros first (or at least, when he is reading a
>> usage of one of these macros).
>
> The answer to this old argument is that this is no different from
> procedures.

Then why not forego macros, and use procedures?

The answer is that macros do things that procedures don't, are extra
linguistic, and are frequently abused in ways that not available in
procedures.

java-programmer >> AspectJ: solution to Java's repetitiveness? Mark Space wrote:

> Then why not forego macros, and use procedures?
>
> The answer is that macros do things that procedures don't, are extra
> linguistic, and are frequently abused in ways that not available in
> procedures.

In comp.lang.scheme, we frequently abuse procedures as well.
(see Guy Steele's ``Lambda: the ultimate goto''). Should we
ban lambda too by that argument?

Aziz,,,

java-programmer >> AspectJ: solution to Java's repetitiveness? Abdulaziz Ghuloum wrote:

> Should we
> ban lambda too by that argument?

Java did....

java-programmer >> AspectJ: solution to Java's repetitiveness? Kenneth P. Turvey wrote:
> On Sun, 20 Apr 2008 22:18:23 -0400, Arne Vajh酶j wrote:
>> You missed the point.
>>
>> Verbose does not mean repetitive.
>
> That's the thing. In Java it often does mean repetitive.

Not in my understanding of those two words.

Arne

java-programmer >> AspectJ: solution to Java's repetitiveness? email***@***.com wrote:
> On Apr 21, 10:44 pm, "Arved Sandstrom" <email***@***.com>
> wrote:
>> Nobody writes code or documentation so fast
>> that their typing prowess (or lack of it) should be a drawback.
>
> Some people do. Read the first comment there:
>
> http://hathawaymix.org/Weblog/2004-06-16
>
> "I recall how one day I walked out of work and my hands hurt so much
> from typing Java code, because Java is so needlessly verbose."

If the complexity of the task is so that it is possible to type
code all day, then Java is very likely not the optimal
language. Java was not intended for such trivial tasks.

The average productivity for a Java programmer are
probably in the 10-50 lines per day range as average.

Software development is about thinking not about
typing.

Arne

PS: The article is rather funny. Statements like "Zope, it turns out,
had already solved most of the problems I had with my homegrown
application server" gives a good impression of why this person
did not like Java.

java-programmer >> AspectJ: solution to Java's repetitiveness? Mark Space wrote:
> Abdulaziz Ghuloum wrote:
>
>> Should we ban lambda too by that argument?
>
> Java did....

No argument then.

Aziz,,,

java-programmer >> AspectJ: solution to Java's repetitiveness? RedGrittyBrick wrote:
> Sometimes I tire of typing code like
>
> CleverGreenThing<WingNut, CorkScrew, BathTub> foo
> = new CleverGreenThing<WingNut, CorkScrew, BathTub>();
>
> I wonder if my IDE can (be trained to) expand "= new();"?

Eclipse does come with a suggestion if you type:
new CTRL/SPACE

Arne

java-programmer >> AspectJ: solution to Java's repetitiveness? "Arved Sandstrom" <email***@***.com> writes:
>Nobody writes code or documentation so fast that their typing
>prowess (or lack of it) should be a drawback.

籋e used this funky ergonomic keyboard

http://www.kinesis-ergo.com/essential.htm

and when he typed it sounded like one of those ratcheting
noisemakers you spin over your head at new years.

I once came to ask him a question that I thought would
take me half an hour to figure out on my own and he
replied, "Well, let's find out" and in less than a minute
he whipped up a piece of code that answered my question.
My jaw was on the floor.?
http://xooglers.blogspot.com/2005/12/they-say-its-darkest-before-dawn.html

java-programmer >> AspectJ: solution to Java's repetitiveness? Mark Space <email***@***.com> wrote:
> @AttribReadOnly
> {
> private String value1;
> private String value2;
> private String value3;
> private String value4;
> }

When I think of how Java and C++ treat differently the
"range" of a public/protected/private keyword, I'd be
very much surprised by one instance of an Annotation
being ever defined to be applied to each of a group of
items.

java-programmer >> AspectJ: solution to Java's repetitiveness? Lew <email***@***.com> wrote:
> The boilerplate code is an advantage, not a problem.

You should really add that to your signature,
as it seems to be your mantra :-)

PS: You surely never omit the "value=" boilerplate when
applying such a single-argument annotations, right?

java-programmer >> AspectJ: solution to Java's repetitiveness? Arne Vajh鴍 wrote:

> PS: The article is rather funny. Statements like "Zope, it turns out,
> had already solved most of the problems I had with my homegrown

In Python! Lots of Java solutions out there too if you just want a
quick download. (Not you personally, you-generically. You<P> as it
were. :))

<http://java-source.net/open-source/content-managment-systems>

Lots of CMS out there, not to mention other web frameworks. Me thinks
the author of the article is setting up straw men that he can easily cut
down. I wonder how his arguments would fare against a more reasonable
opponent....

java-programmer >> AspectJ: solution to Java's repetitiveness? Mark Space wrote:
> Arne Vajh鴍 wrote:
>> PS: The article is rather funny. Statements like "Zope, it turns out,
>> had already solved most of the problems I had with my homegrown
>
> In Python! Lots of Java solutions out there too if you just want a
> quick download. (Not you personally, you-generically. You<P> as it
> were. :))
>
> <http://java-source.net/open-source/content-managment-systems>
>
> Lots of CMS out there, not to mention other web frameworks. Me thinks
> the author of the article is setting up straw men that he can easily cut
> down. I wonder how his arguments would fare against a more reasonable
> opponent....

Java is certainly behind when it comes to number of CMS systems.

But he specifically mentioned app servers. Java is far ahead
when it comes to number of app servers.

Arne

java-programmer >> AspectJ: solution to Java's repetitiveness? Andreas Leitgeb wrote:

> When I think of how Java and C++ treat differently the
> "range" of a public/protected/private keyword, I'd be
> very much surprised by one instance of an Annotation
> being ever defined to be applied to each of a group of
> items.
>

I think there's other reasons why that would never happen, including
that braces at the class level look a lot like static initializer
blocks, and the language (or the compiler) would have to be extended to
add them.

Still I think it would be worthwhile to add some kind of "annotated
block" at the class and the method level.

java-programmer >> AspectJ: solution to Java's repetitiveness?

Stefan Ram wrote:
> "email***@***.com" <email***@***.com> writes:
>
>>>For example, in Lisp, one can write macros for reoccuring
>>>idioms, but anyone who wants to read a program using them has
>>>to learn these macros first (or at least, when he is reading a
>>>usage of one of these macros).
>>
>>The answer to this old argument is that this is no different from
>>procedures.
>
>
> In most programming languages, parameters of procedures are
> strict (they are evaluated at the time of the call). This
> gives the reader of an invocation of a procedure some basic
> information that is always valid. (In languages with
> call-by-value only, one even can deduce that a call will never
> alter an argument variable.)
>
> Macros might have lazy parameters (they do not need to
> evaluate all of their arguments), which opens more
> possibilities for the interpretation of a macro call than for
> the interpretation of a procedure name - even in the presence
> of a good mnemonic macro name. They also might modify an
> argument variable or do other things procedures can't do
> and are overall more powerful than procedure calls.

We might have a forest for the trees situation here, trying to make
sense out of the value of macros by this bizarre metric of how much gets
done with arguments. That is what happens when smart people get to
bullshitting. A simpler approach to the question can be had from simple
application programmers like me, who would point out that we use macros
to hide repetitive boilerplate. Wow. That means the essence of what is
going on at any point in the code is not hard to find, everything that
is not essence is handled by the macro-expansion. The moral of the story
is that the last thing we want to know is what is being done with the
arguments, we just want the name of the macro to be honored by its
performance.

When things go wrong... can you say macroexpand? Sher ya can.

kt

--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/

"I've never read the rulebook. My job is to catch the ball."
-- Catcher Josh Bard after making a great catch on a foul ball
and then sliding into the dugout, which by the rules allowed the
runners to advance one base costing his pitcher a possible shutout
because there was a runner on third base.

"My sig is longer than most of my articles."
-- Kenny Tilton

java-programmer >> AspectJ: solution to Java's repetitiveness? Andreas Leitgeb wrote:
> Lew <email***@***.com> wrote:
>> The boilerplate code is an advantage, not a problem.
>
> You should really add that to your signature,
> as it seems to be your mantra :-)

Actually, it's your mantra. I'm repeating it to help you.

> PS: You surely never omit the "value=" boilerplate when
> applying such a single-argument annotations, right?

Oh, for crying out loud. What a stupid point.

Getters and setters are not required by Java, so don't blame Java. They're a
convention that leads to all sorts of advantages. Now stop being lazy and go
forth to write good code.

--
Lew

java-programmer >> AspectJ: solution to Java's repetitiveness? Wayne wrote:
> OTOH as others have pointed out in previous threads, the JavaBean
> spec is rarely used, so maybe adding more standard annotations
> isn't worth it.

Actually, reading over what others have pointed out in previous threads, it's
that the JavaBean spec is nearly always used. Certain aspects of it are less
popular than others, but much of it is so ingrained in the Java zeitgeist that
people don't even necessarily realize that it's JavaBeans.

--
Lew