Re: ERROR: exceded the 65,535 byte limit
Aeris wrote:
"add()" is not a static method, so you can't call it outside another
method. Try instead:
Lew wrote:
You can't call any method except 'static void main(String [])' from
outside another method. Being static or not is not relevant.
Aeris wrote:
Wrong:
public class MyClass {
private final int value = Integer.parseInt(String.valueOf("14"));
}
Isn't 'String.valueOf("14")' also a 'String' whose value is "14"?
This class is valid, "parseInt" and "valueOf" are methods, called outside a
method, but allowed in variable declaration because static.
Oh, yes, you are correct about it being outside a method, but it is not
outside the initializer. I should have said, "You can't call any method
outside another method, a constructor or an initializer".
But it has nothing whatsoever to do with being static, which was my main
point. Being static or not is irrelevant. You still cannot call any method
free standing, i.e., outside a method, initializer or constructor, and it has
nothing to do with being static or not.
public class Foo
{
NumberFormat fmt = getIntegerInstance();
private final String value = fmt.format( 14L );
}
As you can see, you can call an instance method in an initializer.
So I stand corrected; the actual rule is that you must call a method from
within an initializer, constructor or method, i.e., you cannot have
free-standing logic.
Aeris wrote:
public class MainApplication extends WebApplication {
private List<C> cheeses = new ArrayList<C>() {
{
this.add(new C(???));
Lew wrote:
Use of 'this.' to qualify a method is pointless and also contrary to the
spirit of object orientation.
Aeris wrote:
Remove it if you want :)
I am suggesting that it doesn't belong there in the first place. It implies
that the method is defined in the class, which is not true in the example you
provide, nor generally. The actual method is frequently in a superclass or
subclass. It is actively misleading to prefix a method call with 'this.'.
Lew wrote:
This is a very unusual idiom, to declare a subclass of 'ArrayList' and
fill it within the subclass initializer.
Aeris wrote:
Sure, but this is the only way to declare and initialize a Collection in
same time.
That depends on what you mean by "the same time". The only real requirement
is that the Collection be initialized prior to use, and that can be done in a
constructor or initializer.
There is some others ways (in the constructor for example), but thoses not
work on all cases.
Yes, it does work in all cases.
I am happy to be proven wrong, but I cannot think of an example right now
where on cannot initialize a Collection in an initializer or constructor.
Lew:
The idiom will break on 'final' classes or those with private
constructors.
Aeris wrote:
Yes, but ArrayList is not final.
And private constructor is not a problem in this case, as shown by this
test:
I never said it wouldn't work for 'ArrayList', only that the subclassing
technique is not universal.
Obviously it works for 'ArrayList' because it is not a 'final' class nor one
with a private constructor. Duhhh. What I said was that the idiom would
break on those classes that are 'final' or have a private constructor. There
is no way to misconstrue that to apply to 'ArrayList'.
Lew:
It's also rather advanced to present to someone who is clearly struggling
with the very basics of Java.
Aeris wrote:
It's advanced, but this is the only way to do the job.
No, it is not. You can, as I suggest,
What's wrong with filling the 'ArrayList' (or whatever), not a subtype, in
the constructor or an 'init()' method of 'MainApplication'?
Aeris wrote:
This is not wrong, but depends on the behaviour of the other parts of the
application. This way is guaranteed to work in all cases.
Except those where the class is 'final' or has a private constructor. That is
far from "all cases". Using a constructor or initializer does work in all cases.
In the given exemple, i [sic] see WebApplication, which often say generic proxy
factory, and other very advanced java [sic] behaviour for object handling. This is
so risky to override constructor or implements other methods.
You cannot override a constructor. That is not possible in Java.
And what's wrong to do the job in 3 lines instead of refactor all
constructors and add a new method, especially in test code?
What's wrong is that it creates an unnecessary subclass, it is less clear to
read, it could conflict with reflection idioms, and it doesn't always work.
What do you mean by "refactor all constructors"? The purpose of a constructor
is to construct an object. Filling a collection is certainly a typical task
for construction. The natural place for that is in a constructor (or
initializer).
What's so difficult about putting the same number of lines of code in an
initializer? The line count is the same as your idiom, it's guaranteed to
work even on 'final' or private-constructor classes, it's a more direct
expression of the actual logic, and it doesn't risk screwing up other parts of
the code that might use tricky reflection that responds poorly to unexpected
subtyping.
--
Lew