what's wrong in this program

[VisionSet]

Hello

What's wrong in this program:

error :
E:\programs\java1\SimpleSwing.java:23: cannot resolve symbol
symbol : constructor MyFrame (int,int)
location: class MyFrame
MyFrame mf=new MyFrame(100,100); ^
class MyFrame extends JFrame
{

public void MyFrame()
{
this.setSize(100,100);

}

public void MyFrame(int h,int w)
{
setSize(w,h);

}
}

Remove void from your 'constructors' the compiler thinks they are methods.
And therefore can only see the implicit no argument constructor of JFrame.

public MyFrame(int x, int y)

 

[Madhur Ahuja]

Hello

What's wrong in this program:

error :
E:\programs\java1\SimpleSwing.java:23: cannot resolve symbol
symbol : constructor MyFrame (int,int)
location: class MyFrame
MyFrame mf=new MyFrame(100,100);
^
//////////////////////////////////////

import javax.swing.*;

class MyFrame extends JFrame
{

public void MyFrame()
{
this.setSize(100,100);

}

public void MyFrame(int h,int w)
{
setSize(w,h);

}
}

class SimpleSwing
{
public static void main(String args[])
{
MyFrame mf=new MyFrame(100,100);
mf.show();

}
}

 

[Thomas G. Marshall]

Madhur Ahuja coughed up:

Hello

What's wrong in this program:

error :
E:\programs\java1\SimpleSwing.java:23: cannot resolve symbol
symbol : constructor MyFrame (int,int)
location: class MyFrame
MyFrame mf=new MyFrame(100,100);
^
//////////////////////////////////////

import javax.swing.*;

class MyFrame extends JFrame
{

public void MyFrame()
{
this.setSize(100,100);

}

public void MyFrame(int h,int w)
{
setSize(w,h);

}
}

class SimpleSwing
{
public static void main(String args[])
{
MyFrame mf=new MyFrame(100,100);
mf.show();

}
}

What they said, but just know that this error is sooooooooooo common that
IMO the compiler /really/ should provide a better message.

 

[Madhur Ahuja]

news:[email protected]...

[snip]

Thanks a lot, for a quick answer.

 

[Thomas Fritsch]

Hello

What's wrong in this program:

error :
E:\programs\java1\SimpleSwing.java:23: cannot resolve symbol
symbol : constructor MyFrame (int,int)
location: class MyFrame
MyFrame mf=new MyFrame(100,100);
^
//////////////////////////////////////

import javax.swing.*;

class MyFrame extends JFrame
{

public void MyFrame() public MyFrame()
{
this.setSize(100,100);

}

public void MyFrame(int h,int w)

// Declare constructors without a return type,
// otherwise the compiler misinterprets them as methods
public MyFrame(int h, int w)

{
setSize(w,h);

}
}

class SimpleSwing
{
public static void main(String args[])
{
MyFrame mf=new MyFrame(100,100);
mf.show();

}
}

 

[Mike Schilling]

What they said, but just know that this error is sooooooooooo common that
IMO the compiler /really/ should provide a better message.

So common, and so hard to spot (until someone else points it out.). In
fact, there was no &%^*ing reason to have allowed methods to have the same
name as their containing class in the first place.

 

[Sudsy]

"Thomas G. Marshall" <[email protected]>
wrote in message



So common, and so hard to spot (until someone else points it out.). In
fact, there was no &%^*ing reason to have allowed methods to have the same
name as their containing class in the first place.

So just because it COULD cause confusion, Java should have included yet
another rule expressly forbidding it? People are going to shoot them-
selves in the foot regardless. I'd prefer to have fewer rules and leave
it up to coders to decide what they want to accomplish.
This isn't much different from the on-going debate about accessing
class methods and variables from a (potentially null) instance
reference. Things are the way they are. It's a bit late to go back to
the past and change the rules.
Then again, all these attempts to make Java more like C++... ;-)

 

[Chris Uppal]

So common, and so hard to spot (until someone else points it out.). In
fact, there was no &%^*ing reason to have allowed methods to have the same
name as their containing class in the first place.

Or perhaps the mistake was allowing constructors to have "names" at all.

For instance, by overloading the "this" reserved word, we could've had:

class MyClass
{
private final int thing;

// constructors
public this() { this(0); }
public this(int x) { thing = x; }

// real methods start here
...
}

I think I'd prefer to use the word "new" instead, but "this" does mesh prettily
with the syntax for forwarding constructors.

-- chris

 

[Mike Schilling]

So just because it COULD cause confusion, Java should have included yet
another rule expressly forbidding it?

Because it does cause confusion (uniformly) and because there's no need for
it, yes. If it were illegal, most of us wouldn't even know that, because
we'd never ha ve tried to do it. Are there any classes that use it in the
SDK? In well-known frameworks like Apache commons? Have you ever used it
yourself?

 

[Thomas G. Marshall]

Sudsy coughed up:

So just because it COULD cause confusion, Java should have included
yet another rule expressly forbidding it? People are going to shoot
them- selves in the foot regardless. I'd prefer to have fewer rules
and leave it up to coders to decide what they want to accomplish.

But you need to have a /benefit/ to an ability, and I see none here.

What possible reason do /you/ see for allowing such a thing?

....[rip]...

 

[Michael Borgwardt]

But you need to have a /benefit/ to an ability,
No.

and I see none here.
What possible reason do /you/ see for allowing such a thing?

As Sudsy wrote: the "why" and the befits of allowing it are irrelevant,
what's important is the "why" and the benefits of *disallowing* it,
because the LATTER, not the former, incurs a penalty of an additional rule
and therefore additional complexity in the language specification and
compilers. Apparently the language compilers either just didn't think of
it or decided that the penalty would outweigh the benefit.

 

[Sudsy]

Thomas G. Marshall wrote:

As Sudsy wrote: the "why" and the befits of allowing it are irrelevant,
what's important is the "why" and the benefits of *disallowing* it,
because the LATTER, not the former, incurs a penalty of an additional rule
and therefore additional complexity in the language specification and
compilers. Apparently the language compilers either just didn't think of
it or decided that the penalty would outweigh the benefit.

Thanks, Michael. And if programmers were doing things the "standard"
way then there would never be confusion in the first place. Class
names are supposed to start with a capital letter so contructors
would also. Method names OTOH are never supposed to begin with a
capital letter.
But these are just recommendations. I certainly wouldn't want to
see them as rules mandated by the language. When I'm doing a q&d
(quick-and-dirty) to test some behavioural aspect of the language,
I usually call the class x. So sue me... ;-)

 

[Thomas G. Marshall]

Sudsy coughed up:

Thanks, Michael. And if programmers were doing things the "standard"
way then there would never be confusion in the first place. Class
names are supposed to start with a capital letter so contructors
would also. Method names OTOH are never supposed to begin with a
capital letter.
But these are just recommendations. I certainly wouldn't want to
see them as rules mandated by the language. When I'm doing a q&d
(quick-and-dirty) to test some behavioural aspect of the language,
I usually call the class x. So sue me... ;-)

ARG! And holding down the shift key for a split second takes too long????


I'm not going to sue you, I'm dialing in an air strike......