Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #21017 > unrolled thread

Re: "Hello world!" without a public class?

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: "Hello world!" without a public class? "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-06 02:10 -0800
    Re: "Hello world!" without a public class? Lew <lewbloch@gmail.com> - 2013-01-06 09:43 -0800
      Re: "Hello world!" without a public class? "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-06 09:51 -0800
        Re: "Hello world!" without a public class? Lew <lewbloch@gmail.com> - 2013-01-06 09:58 -0800
          Re: "Hello world!" without a public class? "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-06 10:48 -0800
            Re: "Hello world!" without a public class? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 16:07 -0500
              Re: "Hello world!" without a public class? "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-06 13:21 -0800
                Re: "Hello world!" without a public class? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 16:43 -0500
            Re: "Hello world!" without a public class? Lew <lewbloch@gmail.com> - 2013-01-06 17:24 -0800
        Re: "Hello world!" without a public class? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 15:59 -0500
          Re: "Hello world!" without a public class? "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-06 13:22 -0800
            Re: "Hello world!" without a public class? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 16:35 -0500

#21017 — Re: "Hello world!" without a public class?

>     1.) »public class HelloWorldApp« (because this is most common IIRC)

This the most common they are going to run into in real life and when you get in inheritance explain the difference between the 4 options.   You should also point out (I know I will get flamed for this ;-)) that the only time you do not want to use "public" is in inner classes (which in my opinion should be outlawed anyways)

[toc] | [next] | [standalone]

#21043

Aryeh M. Friedman wrote:
>>     1.) »public class HelloWorldApp« (because this is most common IIRC)
>
> 
> This the most common they are going to run into in real life and when you get in inheritance explain the difference between the 4 options.   You should also point out (I know I will get flamed for this ;-)) that the only time you do not want to use "public" is in inner classes (which in my opinion should be outlawed anyways)

Do you really mean just inner classes? Would you ban all nested classes 
outright?

It would be a very, very boneheaded thing to outlaw inner classes. 
You'd destroy a common idiom for declaring listeners. You'd make lambdas 
impossible. You'd kill one of the most expressive features of Java, that 
was introduced to the language in the first place because of its great 
power.

You are aware that nested classes were added to Java, not there from the 
beginning, yes? There were excellent reasons to do that.

Study the matter.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#21047

On Sunday, January 6, 2013 12:43:53 PM UTC-5, Lew wrote:
> Aryeh M. Friedman wrote:
> 
> >>     1.) »public class HelloWorldApp« (because this is most common IIRC)
> 
> >
> 
> > 
> 
> > This the most common they are going to run into in real life and when you get in inheritance explain the difference between the 4 options.   You should also point out (I know I will get flamed for this ;-)) that the only time you do not want to use "public" is in inner classes (which in my opinion should be outlawed anyways)
> 
> 
> 
> Do you really mean just inner classes? Would you ban all nested classes 
> 
> outright?
> 
> 
> 
> It would be a very, very boneheaded thing to outlaw inner classes. 
> 
> You'd destroy a common idiom for declaring listeners. You'd make lambdas 
> 
> impossible. You'd kill one of the most expressive features of Java, that 
> 
> was introduced to the language in the first place because of its great 
> 
> power.

And get rid of one the most unreadable/widely abused parts of all Java code?   Sounds good to me... almost everything done with inner/nested classes can be done cleaner with post 1.5 constructs that do not require impossible to read code.

[toc] | [prev] | [next] | [standalone]

#21049

Aryeh M. Friedman wrote:
> Lew wrote:
>> Aryeh M. Friedman wrote:
>>>>     1.) »public class HelloWorldApp« (because this is most common IIRC)
>>> This the most common they are going to run into in real life and when you get in inheritance explain the difference between the 4 options.   You should also point out (I know I will get flamed for this ;-)) that the only time you do not want to use "public" is in inner classes (which in my opinion should be outlawed anyways)
> 
>> Do you really mean just inner classes?

Well?

>> Would you ban all nested classes  outright?
> 
>> It would be a very, very boneheaded thing to outlaw inner classes. 
> 
>> You'd destroy a common idiom for declaring listeners. You'd make lambdas 
>> impossible. You'd kill one of the most expressive features of Java, that 
>> was introduced to the language in the first place because of its great 
>> power.
> 
> And get rid of one the most unreadable/widely abused parts of all Java code? 

Conclusion not in evidence.

>  Sounds good to me... almost everything done with inner/nested classes can be

Which, inner or non-inner nested?

> done cleaner with post 1.5 constructs that do not require impossible to read code.

Show the idioms you have in mind. Show how nested classes are "impossible to 
read". They aren't. Unless you don't know Java, in which case don't bother 
arguing about how to improve it. Show that what you have in mind is easier to 
read. Show how you'd do lambdas without them. For God's sake, provide some 
evidence and logic for your point.

Otherwise it's just your personal, non-engineering-based and utterly irrelevant 
opinion.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#21053

On inner classes:

First of all anytime I see more then one class in a .java file I tend to lump them together (i.e. make no distinction between nested and inner).  Now that being said here is a good example of something that is easier to read then either (yes it does get compiled into something very close to inner classes [not nested if I remember the jargon correctly] but no where near as ugly):

Foo.java:

public enum Foo
{
    ACK {
       public void doSomething(SomeClass arg)
       {
          do what ever for ACK
       }
    },
    BAR {
       public void doSomething(SomeClass arg)
       {
         do what ever for BAR
       }
    }
}

Fred.java:

public class Fred
{
     public void someMethod()
     {
        SomeClass sc=new SomeClass(...);
        Foo[] arr=new Foo[]{ACK,BAR};  // typing this for this example so being lazy on syntax

        for(Foo elem:arr)
            elem.doSomething(sc);
     }
}

and voila much more readable then putting a whole rats nest of stuff in the initialization of arr
     }
}

[toc] | [prev] | [next] | [standalone]

#21073

On 1/6/2013 1:48 PM, Aryeh M. Friedman wrote:
>Now that being said here is a good example of something that is easier 
to read then either (yes it does get compiled into something very close 
to inner classes [not nested if I remember the jargon correctly] but no 
where near as ugly):
>
> Foo.java:
>
> public enum Foo
> {
>      ACK {
>         public void doSomething(SomeClass arg)
>         {
>            do what ever for ACK
>         }
>      },
>      BAR {
>         public void doSomething(SomeClass arg)
>         {
>           do what ever for BAR
>         }
>      }
> }
>
> Fred.java:
>
> public class Fred
> {
>       public void someMethod()
>       {
>          SomeClass sc=new SomeClass(...);
>          Foo[] arr=new Foo[]{ACK,BAR};  // typing this for this example so being lazy on syntax
>
>          for(Foo elem:arr)
>              elem.doSomething(sc);
>       }
> }
>
> and voila much more readable then putting a whole rats nest of stuff in the initialization of arr
>       }
> }

Given that the above is both unreadable and un-compilable, then ...

Arne

[toc] | [prev] | [next] | [standalone]

#21075

On Sunday, January 6, 2013 4:07:17 PM UTC-5, Arne Vajhøj wrote:
> On 1/6/2013 1:48 PM, Aryeh M. Friedman wrote:
> 
> >Now that being said here is a good example of something that is easier 
> 
> to read then either (yes it does get compiled into something very close 
> 
> to inner classes [not nested if I remember the jargon correctly] but no 
> 
> where near as ugly):
> 
> >
> 
> > Foo.java:
> 
> >
> 
> > public enum Foo
> 
> > {
> 
> >      ACK {
> 
> >         public void doSomething(SomeClass arg)
> 
> >         {
> 
> >            do what ever for ACK
> 
> >         }
> 
> >      },
> 
> >      BAR {
> 
> >         public void doSomething(SomeClass arg)
> 
> >         {
> 
> >           do what ever for BAR
> 
> >         }
> 
> >      }
> 
> > }
> 
> >
> 
> > Fred.java:
> 
> >
> 
> > public class Fred
> 
> > {
> 
> >       public void someMethod()
> 
> >       {
> 
> >          SomeClass sc=new SomeClass(...);
> 
> >          Foo[] arr=new Foo[]{ACK,BAR};  // typing this for this example so being lazy on syntax
> 
> >
> 
> >          for(Foo elem:arr)
> 
> >              elem.doSomething(sc);
> 
> >       }
> 
> > }
> 
> >
> 
> > and voila much more readable then putting a whole rats nest of stuff in the initialization of arr
> 
> >       }
> 
> > }
> 
> 
> 
> Given that the above is both unreadable and un-compilable, then ...
> 
> 
> 
> Arne

Ok here is some actual working code that effectively does the same thing with the psedocode filled in (including the command lines):

% cat Foo.java 
public enum Foo
{
	ACK {
		public String doSomething(String arg)
		{
			return "ACK: "+arg;
		}
	},
	BAR {
		public String doSomething(String arg)
		{
			return "BAR: "+arg;
		}
	};

	public abstract String doSomething(String arg);
}
% cat Fred.java 
public class Fred
{
	public static void main(String[] args)
	{
		for(Foo elem:new Foo[]{Foo.ACK,Foo.BAR})
			System.out.println(elem.doSomething("I am doing something"));
	}
}
% javac Fred.java 
% java Fred
ACK: I am doing something
BAR: I am doing something

Now please tell me that does not replace inner classes (the enum constants are compiled as inner classes and not just straight data constants).

[toc] | [prev] | [next] | [standalone]

#21078

On 1/6/2013 4:21 PM, Aryeh M. Friedman wrote:
> On Sunday, January 6, 2013 4:07:17 PM UTC-5, Arne Vajhøj wrote:
>> Given that the above is both unreadable and un-compilable, then ...
>
> Ok here is some actual working code that effectively does the same thing with the psedocode filled in (including the command lines):
>
> % cat Foo.java
> public enum Foo
> {
> 	ACK {
> 		public String doSomething(String arg)
> 		{
> 			return "ACK: "+arg;
> 		}
> 	},
> 	BAR {
> 		public String doSomething(String arg)
> 		{
> 			return "BAR: "+arg;
> 		}
> 	};
>
> 	public abstract String doSomething(String arg);
> }
> % cat Fred.java
> public class Fred
> {
> 	public static void main(String[] args)
> 	{
> 		for(Foo elem:new Foo[]{Foo.ACK,Foo.BAR})
> 			System.out.println(elem.doSomething("I am doing something"));
> 	}
> }
> % javac Fred.java
> % java Fred
> ACK: I am doing something
> BAR: I am doing something
>
> Now please tell me that does not replace inner classes (the enum constants are compiled as inner classes and not just straight data constants).

Well - now it compiles.

But:
1) you have made the code a lot more difficult to read by using
    an enum for something non-enumish, and the same effect can
    be had using normal classes just with a few more keywords
2) it is only relevant for static nested classes as it does not
    provide the capturing the non-static nested classes do
3) it is only relevant for static nested classes that implements
    not use that extends due to limitations on enum

In other words: no beef.

Arne

[toc] | [prev] | [next] | [standalone]

#21095

Aryeh M. Friedman wrote:
> On inner classes:
> ...
> (yes it does get compiled into something very close to inner classes [not nested if I remember the jargon correctly]

Terminology:  A nested type (class or interface) is a member of another type. 
(JLS §8.5)

There are two kinds of nested classes, static and inner, per the JLS. 
By definition, an inner class is a nested class whose declaration does not include the keyword 'static'.

"The static keyword may modify the declaration of a member type C within the 
body of a non-inner class or interface T. Its effect is to declare that C is 
not an inner class."
(JLS §8.5.1)

>  but no where near as ugly):

These get compiled exactly into inner classes.

> Foo.java:
> 
> public enum Foo
> {
>     ACK {

@Override

>        public void doSomething(SomeClass arg)
>        {
>           do what ever for ACK
>        }
>     },
> ...
> }

In this case the enum, itself a cover for compiler-supported boilerplate for a
class with static constant members, also covers for the boilerplate of inner 
class declarations in those constants.

Much as the lambdas I mentioned earlier cover for the boilerplate of inner-
class declarations of SAM interface implementations.

Neither of these work without inner classes, so your proposal to eliminate 
inner classes would break them.

> Fred.java:
> ...
> and voila much more readable then putting a whole rats nest of stuff in the initialization of arr

Perhaps, but it doesn't prove the point, because it relies on inner classes.

And your claim that it's "much more readable" is not really proven.

public abstract class Bar
{
  private final String rep;
  abstract public void doSomething(Some arg);
  private Bar(String r) 
  {
    this.rep = r;
  }
  public static final BAR = new Bar("BAR") 
    {
      @Override
      public void doSomething(Some arg) 
      { 
    //    do what ever for BAR 
      } 
    };
}

The only part of the anonymous class declaration that differs is the 

new Bar("BAR") 

Not even "much" different in readability, let alone "very much".

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#21072

On 1/6/2013 12:51 PM, Aryeh M. Friedman wrote:
> On Sunday, January 6, 2013 12:43:53 PM UTC-5, Lew wrote:
>> Aryeh M. Friedman wrote:
>>> This the most common they are going to run into in real life and
>>> when you get in inheritance explain the difference between the 4
>>> options.   You should also point out (I know I will get flamed
>>> for this ;-)) that the only time you do not want to use "public"
>>> is in inner classes (which in my opinion should be outlawed
>>> anyways)
>>
>> Do you really mean just inner classes? Would you ban all nested
>> classes
>> outright?
>>
>> It would be a very, very boneheaded thing to outlaw inner classes.
>>
>> You'd destroy a common idiom for declaring listeners. You'd make
>> lambdas
>>
>> impossible. You'd kill one of the most expressive features of Java,
>> that
>>
>> was introduced to the language in the first place because of its
>> great
>> power.
>
> And get rid of one the most unreadable/widely abused parts of all
> Java code?   Sounds good to me... almost everything done with
> inner/nested classes can be done cleaner with post 1.5 constructs
> that do not require impossible to read code.

What post 1.5 constructs can replace inner classes?

Arne

[toc] | [prev] | [next] | [standalone]

#21076

On Sunday, January 6, 2013 3:59:30 PM UTC-5, Arne Vajhøj wrote:
> On 1/6/2013 12:51 PM, Aryeh M. Friedman wrote:
> 
> > On Sunday, January 6, 2013 12:43:53 PM UTC-5, Lew wrote:
> 
> >> Aryeh M. Friedman wrote:
> 
> >>> This the most common they are going to run into in real life and
> 
> >>> when you get in inheritance explain the difference between the 4
> 
> >>> options.   You should also point out (I know I will get flamed
> 
> >>> for this ;-)) that the only time you do not want to use "public"
> 
> >>> is in inner classes (which in my opinion should be outlawed
> 
> >>> anyways)
> 
> >>
> 
> >> Do you really mean just inner classes? Would you ban all nested
> 
> >> classes
> 
> >> outright?
> 
> >>
> 
> >> It would be a very, very boneheaded thing to outlaw inner classes.
> 
> >>
> 
> >> You'd destroy a common idiom for declaring listeners. You'd make
> 
> >> lambdas
> 
> >>
> 
> >> impossible. You'd kill one of the most expressive features of Java,
> 
> >> that
> 
> >>
> 
> >> was introduced to the language in the first place because of its
> 
> >> great
> 
> >> power.
> 
> >
> 
> > And get rid of one the most unreadable/widely abused parts of all
> 
> > Java code?   Sounds good to me... almost everything done with
> 
> > inner/nested classes can be done cleaner with post 1.5 constructs
> 
> > that do not require impossible to read code.
> 
> 
> 
> What post 1.5 constructs can replace inner classes?
> 
> 
> 
> Arne

See previous message

[toc] | [prev] | [next] | [standalone]

#21077

On 1/6/2013 4:22 PM, Aryeh M. Friedman wrote:
> On Sunday, January 6, 2013 3:59:30 PM UTC-5, Arne Vajhøj wrote:
>> On 1/6/2013 12:51 PM, Aryeh M. Friedman wrote:
>>> On Sunday, January 6, 2013 12:43:53 PM UTC-5, Lew wrote:
>>>> Aryeh M. Friedman wrote:
>>>>> This the most common they are going to run into in real life and
>>>>> when you get in inheritance explain the difference between the 4
>>>>> options.   You should also point out (I know I will get flamed
>>>>> for this ;-)) that the only time you do not want to use "public"
>>>>> is in inner classes (which in my opinion should be outlawed
>>>>> anyways)
>>>> Do you really mean just inner classes? Would you ban all nested
>>>> classes
>>>> outright?
>>>>
>>>> It would be a very, very boneheaded thing to outlaw inner classes.
>>>>
>>>> You'd destroy a common idiom for declaring listeners. You'd make
>>>> lambdas
>>>> impossible. You'd kill one of the most expressive features of Java,
>>>> that
>>>> was introduced to the language in the first place because of its
>>>> great
>>>> power.
>>> And get rid of one the most unreadable/widely abused parts of all
>>> Java code?   Sounds good to me... almost everything done with
>>> inner/nested classes can be done cleaner with post 1.5 constructs
>>> that do not require impossible to read code.
>> What post 1.5 constructs can replace inner classes?
>
> See previous message

You you believe that that enum has made inner classes obsolete.

Well - I had not thought about that.

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web