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

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

no more primitive data types in Java (JDK 10+). What do you think?

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

Contents

  no more primitive data types in Java (JDK 10+). What do you think? "Nasser M. Abbasi" <nma@12000.org> - 2012-04-19 18:27 -0500
    Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-19 20:02 -0400
      Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-19 17:31 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? Robert Klemme <shortcutter@googlemail.com> - 2012-04-20 15:45 +0200
          Re: no more primitive data types in Java (JDK 10+). What do you think? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-20 15:05 +0000
            Re: no more primitive data types in Java (JDK 10+). What do you think? Robert Klemme <shortcutter@googlemail.com> - 2012-04-20 19:32 +0200
          Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-20 20:47 -0700
      Re: no more primitive data types in Java (JDK 10+). What do you think? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-04-19 17:45 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-19 21:22 -0400
        Re: no more primitive data types in Java (JDK 10+). What do you think? "Nasser M. Abbasi" <nma@12000.org> - 2012-04-19 21:16 -0500
          Re: no more primitive data types in Java (JDK 10+). What do you think? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-04-19 23:11 -0700
    Re: no more primitive data types in Java (JDK 10+). What do you think? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-19 21:35 -0300
      Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-19 21:31 -0400
      Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-19 19:22 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-04-19 23:15 -0700
          Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-20 07:45 -0700
            Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-20 08:20 -0700
              Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-20 19:57 -0700
                Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 04:25 -0700
                  Re: no more primitive data types in Java (JDK 10+). What do you think? Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-04-21 07:05 -0500
                    Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-21 07:42 -0700
                      Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 12:55 -0700
                        Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-21 13:27 -0700
                          Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 13:34 -0700
                            Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-21 14:01 -0700
                            Re: no more primitive data types in Java (JDK 10+). What do you think? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-21 23:48 +0000
                              Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 17:46 -0700
          Re: no more primitive data types in Java (JDK 10+). What do you think? Gene Wirchenko <genew@ocis.net> - 2012-04-20 08:08 -0700
            Re: no more primitive data types in Java (JDK 10+). What do you think? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-20 16:46 +0000
              Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-20 12:52 -0700
          Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-20 08:17 -0700
            Re: no more primitive data types in Java (JDK 10+). What do you think? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-04-20 09:02 -0700
              Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-20 12:48 -0700
              Re: no more primitive data types in Java (JDK 10+). What do you think? David Lamb <dalamb@cs.queensu.ca> - 2012-04-20 21:08 -0400
                Re: no more primitive data types in Java (JDK 10+). What do you think? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-21 01:55 +0000
                  Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 04:28 -0700
    Re: no more primitive data types in Java (JDK 10+). What do you think? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-04-19 19:36 -0500
    Re: no more primitive data types in Java (JDK 10+). What do you think? Tsukino Usagi <usagi@tsukino.ca> - 2012-04-20 15:27 +0900
      Re: no more primitive data types in Java (JDK 10+). What do you think? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-20 07:04 -0300
        Re: no more primitive data types in Java (JDK 10+). What do you think? Tsukino Usagi <usagi@tsukino.ca> - 2012-04-20 22:17 +0900
          Re: no more primitive data types in Java (JDK 10+). What do you think? Robert Klemme <shortcutter@googlemail.com> - 2012-04-20 15:59 +0200
        Re: no more primitive data types in Java (JDK 10+). What do you think? Thufir <hawat.thufir@gmail.com> - 2012-04-20 14:21 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-20 19:11 -0400
      Re: no more primitive data types in Java (JDK 10+). What do you think? Tsukino Usagi <usagi@tsukino.ca> - 2012-04-20 22:16 +0900
        Re: no more primitive data types in Java (JDK 10+). What do you think? Robert Klemme <shortcutter@googlemail.com> - 2012-04-20 15:55 +0200
      Re: no more primitive data types in Java (JDK 10+). What do you think? Patricia Shanahan <pats@acm.org> - 2012-04-20 07:49 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-20 19:19 -0400
          Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-21 07:58 -0700
      Re: no more primitive data types in Java (JDK 10+). What do you think? rossum <rossum48@coldmail.com> - 2012-04-20 20:08 +0100
        Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-20 12:54 -0700
          Re: no more primitive data types in Java (JDK 10+). What do you think? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-20 21:48 +0000
            Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-20 16:45 -0700
              Re: no more primitive data types in Java (JDK 10+). What do you think? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-21 01:56 +0000
                Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 04:35 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? Jim Janney <jjanney@shell.xmission.com> - 2012-04-20 16:24 -0600
      Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-20 19:08 -0400
      Re: no more primitive data types in Java (JDK 10+). What do you think? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-04-20 18:14 -0500
        Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-20 19:22 -0400
        Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-20 20:36 -0400
    Re: no more primitive data types in Java (JDK 10+). What do you think? Roedy Green <see_website@mindprod.com.invalid> - 2012-04-20 05:33 -0700
      Re: no more primitive data types in Java (JDK 10+). What do you think? Bernd Nawothnig <Bernd.Nawothnig@t-online.de> - 2012-04-20 20:53 +0200
        Re: no more primitive data types in Java (JDK 10+). What do you think? Gene Wirchenko <genew@ocis.net> - 2012-04-20 13:36 -0700
          Re: no more primitive data types in Java (JDK 10+). What do you think? Bernd Nawothnig <Bernd.Nawothnig@t-online.de> - 2012-04-21 10:20 +0200
            Re: no more primitive data types in Java (JDK 10+). What do you think? Gene Wirchenko <genew@ocis.net> - 2012-04-23 10:24 -0700
              Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-24 14:39 -0700
                Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <lewbloch@gmail.com> - 2012-04-24 15:06 -0700
                  Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-24 17:07 -0700
                    Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-25 00:48 -0700
                      Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-25 08:20 -0700
                        Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-25 08:59 -0700
                          Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-25 10:32 -0700
                Re: no more primitive data types in Java (JDK 10+). What do you think? Tsukino Usagi <usagi@tsukino.ca> - 2012-04-29 23:03 +0900
                  Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-29 10:28 -0700
        Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-21 08:55 -0700
          Re: no more primitive data types in Java (JDK 10+). What do you think? Lew <noone@lewscanon.com> - 2012-04-21 12:56 -0700
            Re: no more primitive data types in Java (JDK 10+). What do you think? BGB <cr88192@hotmail.com> - 2012-04-21 13:41 -0700
    Re: no more primitive data types in Java (JDK 10+). What do you think? Silvio Bierman <silvio@moc.com> - 2012-04-20 16:50 +0200
      Re: no more primitive data types in Java (JDK 10+). What do you think? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-20 19:04 -0400

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#13692

On 04/20/2012 03:17 PM, Tsukino Usagi wrote:
> On 4/20/2012 7:04 PM, Arved Sandstrom wrote:
>> On 12-04-20 03:27 AM, Tsukino Usagi wrote:
>>> On 4/20/2012 8:27 AM, Nasser M. Abbasi wrote:
>>>>
>>>> On page 42, it says:
>>>>
>>>> "Unified type system (JDK 10+)
>>>> No more primitives, make everything objects"
>>>>
>>>> I've seen very little discussion on this very important
>>>> subject.
>>>>
>>>> What do the experts here think of the idea?
>>>
>>> It's impossible. Whatever they mean when they say "remove primitives"
>>> cannot possibly be what those words actually mean. Just think, how would
>>> it be possible to state a = a + 1 without the number 1? Ok, so you can
>>> use .add(Integer x). But how precisely do you call it? .add(1)? There's
>>> still a 1. And what's worse is if numbers act like objects, which
>>> introduces it's own dangerous problem. Is the number 5 really 5, or is
>>> it something else? Treating primitives like objects, without them
>>> actually being objects, is UN-neccessary and confusing.
>>>
>>> 5.length() or 5.size()? Well if 5 is an object I should be able to
>>> over-ride it.
>>>
>>> Class 6 Extends 14 {}
>>>
>>> Is that what they mean, or do they mean they will just treat numbers
>>> /like/ objects? I guess I need more information. In the absence of a
>>> good reason, I don't believe such a change will ever actually make it
>>> into Java.
>>
>> However they do things there will be problems and concerns. What you
>> talk about is not likely to be one of them. In a system where all things
>> are objects, numeric literals are objects: they are syntactic sugar.
>>
>> a = 2;
>>
>> really means
>>
>> a = new Integer(2);

Rather

a = Interer.valueOf(2)

as it is done already today with autoboxing.  But yes, the literal can 
be translated to anything.

>> and
>>
>> a = a + 1;
>>
>> means that a is some Number and you're adding Integer(1) to it. Who
>> cares that underneath the hood the compiler translates that to (int)13 +
>> (int)1?
>>
>> Just because you've got literals doesn't mean that you need primitives.
>>
>> As for instance calls on a literal, you and I already do that with
>> String literals. E.g. "some string".length().
>>
>> I think you can see that in your example '5' is an instance; Java is
>> class-oriented for inheritance/extension, not object-oriented, so you
>> won't be extending an instance. But yes, we'd expect that you could do
>> 5.someMethod(), for instance methods that make sense.
>>
>> AHS
>
> I get what your saying, my point was exactly that requiring Integer(1)
> is ridiculous. If your going to type "1", type "1" and be done with it.

I am sorry, but that statement proves that you did not get the point.

Cheers

	robert

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

#13716

On Fri, 20 Apr 2012 07:04:40 -0300, Arved Sandstrom wrote:

> But yes, we'd expect that you could do 5.someMethod(), for instance
> methods that make sense.


Which, in ruby, is an awesome feature.


-Thufir

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

#13721

On 4/20/2012 6:04 AM, Arved Sandstrom wrote:
> On 12-04-20 03:27 AM, Tsukino Usagi wrote:
>> On 4/20/2012 8:27 AM, Nasser M. Abbasi wrote:
>>>
>>> On page 42, it says:
>>>
>>> "Unified type system (JDK 10+)
>>> No more primitives, make everything objects"
>>>
>>> I've seen very little discussion on this very important
>>> subject.
>>>
>>> What do the experts here think of the idea?
>>
>> It's impossible. Whatever they mean when they say "remove primitives"
>> cannot possibly be what those words actually mean. Just think, how would
>> it be possible to state a = a + 1 without the number 1? Ok, so you can
>> use .add(Integer x). But how precisely do you call it? .add(1)? There's
>> still a 1. And what's worse is if numbers act like objects, which
>> introduces it's own dangerous problem. Is the number 5 really 5, or is
>> it something else? Treating primitives like objects, without them
>> actually being objects, is UN-neccessary and confusing.
>>
>> 5.length() or 5.size()? Well if 5 is an object I should be able to
>> over-ride it.
>>
>> Class 6 Extends 14 {}
>>
>> Is that what they mean, or do they mean they will just treat numbers
>> /like/ objects? I guess I need more information. In the absence of a
>> good reason, I don't believe such a change will ever actually make it
>> into Java.
>
> However they do things there will be problems and concerns. What you
> talk about is not likely to be one of them. In a system where all things
> are objects, numeric literals are objects: they are syntactic sugar.
>
> a = 2;
>
> really means
>
> a = new Integer(2);
>
> and
>
> a = a + 1;
>
> means that a is some Number and you're adding Integer(1) to it. Who
> cares that underneath the hood the compiler translates that to (int)13 +
> (int)1?
>
> Just because you've got literals doesn't mean that you need primitives.

I would expect a split in ref and val types just both deriving from
Object.

Arne

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

#13687

On 4/20/2012 3:36 PM, Stefan Ram wrote:
> Tsukino Usagi<usagi@tsukino.ca>  writes:
>> Is that what they mean, or do they mean they will just treat numbers
>> /like/ objects? I guess I need more information. In the absence of a
>> good reason, I don't believe such a change will ever actually make it
>> into Java.
>
>    I suggest, you might learn some Smalltalk or at least Ruby.
>

I can see myself learning smalltalk for the bragging rights, but there's 
no need to bring ruby into this. Ruby has serious problems and I don't 
understand why they don't just fix them.

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

#13690

On 04/20/2012 03:16 PM, Tsukino Usagi wrote:
> On 4/20/2012 3:36 PM, Stefan Ram wrote:
>> Tsukino Usagi<usagi@tsukino.ca> writes:
>>> Is that what they mean, or do they mean they will just treat numbers
>>> /like/ objects? I guess I need more information. In the absence of a
>>> good reason, I don't believe such a change will ever actually make it
>>> into Java.
>>
>> I suggest, you might learn some Smalltalk or at least Ruby.
>>
>
> I can see myself learning smalltalk for the bragging rights, but there's
> no need to bring ruby into this. Ruby has serious problems and I don't
> understand why they don't just fix them.

I don't know what "serious problems" you are talking about and this is 
probably not the place to discuss them either.  But Stefan's hint was a 
good one in this context because MRI has a clean object model for the 
user with not too bad performance for primitive numbers.  (see ref to 
Wikipedia article elsewhere in this thread)

Kind regards

	robert

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

#13694

On 4/19/2012 11:27 PM, Tsukino Usagi wrote:
...
> 5.length() or 5.size()? Well if 5 is an object I should be able to
> over-ride it.
>
> Class 6 Extends 14 {}
...

I'm sure if the literal 6 were mapped to an Object, it would be an
instance of Integer or some other final class, preventing overriding.

Patricia

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

#13723

On 4/20/2012 10:49 AM, Patricia Shanahan wrote:
> On 4/19/2012 11:27 PM, Tsukino Usagi wrote:
> ...
>> 5.length() or 5.size()? Well if 5 is an object I should be able to
>> over-ride it.
>>
>> Class 6 Extends 14 {}
> ...
>
> I'm sure if the literal 6 were mapped to an Object, it would be an
> instance of Integer or some other final class, preventing overriding.

In C# value types can not be extended.

In Scala value types is a fixed set.

So it seem very likely that int would be final if this
change were implemented.

Arne

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

#13747

On 4/20/2012 4:19 PM, Arne Vajhøj wrote:
> On 4/20/2012 10:49 AM, Patricia Shanahan wrote:
>> On 4/19/2012 11:27 PM, Tsukino Usagi wrote:
>> ...
>>> 5.length() or 5.size()? Well if 5 is an object I should be able to
>>> over-ride it.
>>>
>>> Class 6 Extends 14 {}
>> ...
>>
>> I'm sure if the literal 6 were mapped to an Object, it would be an
>> instance of Integer or some other final class, preventing overriding.
>
> In C# value types can not be extended.
>
> In Scala value types is a fixed set.
>
> So it seem very likely that int would be final if this
> change were implemented.
>

yes, probably final, and likely more so with the "object" aspects of all 
this essentially being faked in the VM as well, because actually 
allocating a memory object for every integer would be a bit, expensive.

it could also work out that:
Integer iobj=new Integer(5);

doesn't actually create a new heap object in the first place, it only 
appears to do so, and behaves as if it had done so.

this is the great fun of compilers and VMs:
what is going on in the language, and what is going on nearer the actual 
HW, need not really be all that similar.

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

#13707

On Fri, 20 Apr 2012 15:27:51 +0900, Tsukino Usagi <usagi@tsukino.ca>
wrote:

>Class 6 Extends 14 {}
abstract class Peano { }

class 0 extends Peano { }

class 1 extends 0 { }

class 2 extends 1 { }

...


rossum

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

#13711

rossum wrote:
> Tsukino Usagi  wrote:
> 
> >Class 6 Extends 14 {}
> abstract class Peano { }
> 
> class 0 extends Peano { }
> 
> class 1 extends 0 { }
> 
> class 2 extends 1 { }
> 
> ...

And that's relevant because ... ?

Do you think they'll suddenly allow leading digits in class identifiers for Java code? I think not.

It's all a tempest in a teapot anyway.

--
Lew

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

#13717

Lew <lewbloch@gmail.com> wrote:
(snip)
>> >Class 6 Extends 14 {}
>> abstract class Peano { }
>> class 0 extends Peano { }

(snip)
> And that's relevant because ... ?

> Do you think they'll suddenly allow leading digits in class 
> identifiers for Java code? I think not.

As I remember, all unicode letters are allowed. There are plenty
that could be confusing to readers. Maybe there aren't any that
look like roman digits, though. There are many that look like,
but aren't the same character as, roman alphabet letters.

-- glen

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

#13725

glen herrmannsfeldt wrote but callously failed to attribute his citations:
> Lew wrote:
> (snip)
>>>>Class 6 Extends 14 {}  <=== Tsukino Usagi  wrote
>>> abstract class Peano { }  <=== rossum wrote 
>>> class 0 extends Peano { }
> 
> (snip)
>> And that's relevant because ... ?
> 
>> Do you think they'll suddenly allow leading digits in class 
>> identifiers for Java code? I think not.
> 
> As I remember, all unicode [sic] letters are allowed. There are plenty

As I looked up in the JLS, that's not true. Leading digits are not permitted.

"An identifier is an unlimited-length sequence of Java letters and Java digits, the first of which must be a Java letter."
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.8>

The JLS trumps your memory.

> that could be confusing to readers. Maybe there aren't any that
> look like roman digits, though. There are many that look like,
> but aren't the same character as, roman alphabet letters.

But those characters are not used to represent integers, so are not germane to this conversation.

The question at hand was the potential legitimization of glyphs that represent integers to be used as class names that inherit from other classes. Those glyphs are not currently allowed to be leading characters of identifiers, so unless that changes, rossum's construct will never be legal.

-- 
Lew

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

#13731

Lew <lewbloch@gmail.com> wrote:

(snip, I wrote)
>> As I remember, all unicode [sic] letters are allowed. 
>> There are plenty

> As I looked up in the JLS, that's not true. Leading digits are 
> not permitted.

What isn't true? I wrote letters, you wrote digits. Unicode has many
of each, but the letters aren't digits and the digits aren't letters.

> "An identifier is an unlimited-length sequence of Java letters 
> and Java digits, the first of which must be a Java letter."
> <http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.8>

> The JLS trumps your memory.

and there are a lot more than 52 Java letters.

>> that could be confusing to readers. Maybe there aren't any that
>> look like roman digits, though. There are many that look like,
>> but aren't the same character as, roman alphabet letters.

> But those characters are not used to represent integers, 
> so are not germane to this conversation.

True, but it could be confusing. Well, we already have the 
confusion between 0 and O, but most are used to that by now.
Now, name a variable \u039f and see how confusing it can be.

> The question at hand was the potential legitimization of 
> glyphs that represent integers to be used as class names that 
> inherit from other classes. Those glyphs are not currently 
> allowed to be leading characters of identifiers, so unless 
> that changes, rossum's construct will never be legal.

I don't know of a visual representation for all the legal
Java letters, but yes they should be disjoint from the digits
that can be used in numeric constants.

-- glen

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

#13741

glen herrmannsfeldt wrote:
> Lew wrote:
>
> (snip, I wrote)
>>> As I remember, all unicode [sic] letters are allowed.
>>> There are plenty
>
>> As I looked up in the JLS, that's not true. Leading digits are
>> not permitted.
>
> What isn't true? I wrote letters, you wrote digits. Unicode has many
> of each, but the letters aren't digits and the digits aren't letters.

It isn't true that a construct such as

  class 0 extends Peano

could be in conflict with numbers as objects, as you were trying to claim.

>
>> "An identifier is an unlimited-length sequence of Java letters
>> and Java digits, the first of which must be a Java letter."
>> <http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.8>
>
>> The JLS trumps your memory.
>
> and there are a lot more than 52 Java letters.
>
>>> that could be confusing to readers. Maybe there aren't any that
>>> look like roman digits, though. There are many that look like,
>>> but aren't the same character as, roman alphabet letters.
>
>> But those characters are not used to represent integers,
>> so are not germane to this conversation.
>
> True, but it could be confusing. Well, we already have the

Maybe, slightly, but that was irrelevant to the point in the conversation, 
which was a discussion of whether numbers as objects implied legitimacy for 
having a numerically-named type derive from another. Your statement about 
non-digit Unicode characters is a red herring in that context.

> confusion between 0 and O, but most are used to that by now.
> Now, name a variable \u039f and see how confusing it can be.

What does that have to do with whether digit glyphs could be syntactically 
valid as identifiers for descendant types?>

>> The question at hand was the potential legitimization of
>> glyphs that represent integers to be used as class names that
>> inherit from other classes. Those glyphs are not currently
>> allowed to be leading characters of identifiers, so unless
>> that changes, rossum's construct will never be legal.
>
> I don't know of a visual representation for all the legal
> Java letters, but yes they should be disjoint from the digits
> that can be used in numeric constants.

And are, as cited. This whole thing is an attempt to resolve your tangential 
comment as not pertinent to the point that was being made at the time.

Confusing non-digit glyphs have nothing to do with whether digit glyphs can 
lead off identifiers. Pretending that you broke the rules is not the same as 
actually breaking the rules.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

#13718

rossum <rossum48@coldmail.com> writes:

> On Fri, 20 Apr 2012 15:27:51 +0900, Tsukino Usagi <usagi@tsukino.ca>
> wrote:
>
>>Class 6 Extends 14 {}
> abstract class Peano { }
>
> class 0 extends Peano { }
>
> class 1 extends 0 { }
>
> class 2 extends 1 { }
>
> ...

What about the reals? :-)

-- 
Jim Janney

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

#13720

On 4/20/2012 2:27 AM, Tsukino Usagi wrote:
> On 4/20/2012 8:27 AM, Nasser M. Abbasi wrote:
>>
>> On page 42, it says:
>>
>> "Unified type system (JDK 10+)
>> No more primitives, make everything objects"
>>
>> I've seen very little discussion on this very important
>> subject.
>>
>> What do the experts here think of the idea?
>
> It's impossible.

Since several languages has already implemented this feature, then
it is obviously not impossible.

>                Whatever they mean when they say "remove primitives"
> cannot possibly be what those words actually mean. Just think, how would
> it be possible to state a = a + 1 without the number 1? Ok, so you can
> use .add(Integer x). But how precisely do you call it? .add(1)? There's
> still a 1. And what's worse is if numbers act like objects, which
> introduces it's own dangerous problem. Is the number 5 really 5, or is
> it something else? Treating primitives like objects, without them
> actually being objects, is UN-neccessary and confusing.
>
> 5.length() or 5.size()?

I am not sure about those, but toString() should obviously
be there.

>                     Well if 5 is an object I should be able to
> over-ride it.
>
> Class 6 Extends 14 {}

????

6 and 14 are instances of int not types.

And not all types are extendable.

Arne

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

#13722

On 4/20/2012 1:27 AM, Tsukino Usagi wrote:
> It's impossible. Whatever they mean when they say "remove primitives"
>  cannot possibly be what those words actually mean.

The term probably refers to unifying the type hierarchy such that the 
primitive types are logically subtypes of Object. In other words, remove 
the distinction between primitive and reference types.

> 5.length() or 5.size()? Well if 5 is an object I should be able to
> over-ride it.
>
> Class 6 Extends 14 {}

5 is an object instance, not a type that can be extended. Just like I 
can't say class Allegro extends System.out {}...

> Is that what they mean, or do they mean they will just treat numbers
>  /like/ objects? I guess I need more information. In the absence of a
>  good reason, I don't believe such a change will ever actually make
> it into Java.

My guess is the main goal is to allow things like a true List<int> 
(where the T data would be `int data') instead of List<Integer>.

-- 
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

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

#13724

On 4/20/2012 7:14 PM, Joshua Cranmer wrote:
> On 4/20/2012 1:27 AM, Tsukino Usagi wrote:
>> It's impossible. Whatever they mean when they say "remove primitives"
>> cannot possibly be what those words actually mean.
>
> The term probably refers to unifying the type hierarchy such that the
> primitive types are logically subtypes of Object. In other words, remove
> the distinction between primitive and reference types.
>
>> 5.length() or 5.size()? Well if 5 is an object I should be able to
>> over-ride it.
>>
>> Class 6 Extends 14 {}
>
> 5 is an object instance, not a type that can be extended. Just like I
> can't say class Allegro extends System.out {}...
>
>> Is that what they mean, or do they mean they will just treat numbers
>> /like/ objects? I guess I need more information. In the absence of a
>> good reason, I don't believe such a change will ever actually make
>> it into Java.
>
> My guess is the main goal is to allow things like a true List<int>
> (where the T data would be `int data') instead of List<Integer>.

Which combined with the generics change also mentioned in the
roadmap would improve performance of collections of simple
types.

Arne

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

#13728

On 4/20/2012 8:22 PM, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> "Our customers /don't want/ closures"
>
>    Sorry for the lack of context!
>
>    I was referring to a quotation about the design of Java:
>
>        »Guy Steele wrote:
>
>        Actually, the prototype implementation *did* allow non-final
>        variables to be referenced from within inner classes.  There was
>        an outcry from *users*, complaining that they did not want this!«
>
> http://madbean.com/2003/mb2003-49/

The world evolves.

It happens frequently that C# users get confused about this.

But many seems to think that the benefits outweigh the problems.

So ...

Arne

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

#13685

On Thu, 19 Apr 2012 18:27:43 -0500, "Nasser M. Abbasi" <nma@12000.org>
wrote, quoted or indirectly quoted someone who said :

>    "Unified type system (JDK 10+)
>     No more primitives, make everything objects"

This is the way Eiffel works, but under the covers there are still
primitives. Perhaps what they have in mind for Java, more intelligent
boxing. At least at the low levels of the JVM you need primitives.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
When you were a child, if you did your own experiment
to see if it was better to put to cocoa into your cup first
or the hot milk first, then you likely have the programmer gene..

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web