Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > no more primitive data types in Java (JDK 10+). What do you think?

Reply
Thread Tools

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

 
 
Lew
Guest
Posts: n/a
 
      04-20-2012
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
 
Reply With Quote
 
 
 
 
Gene Wirchenko
Guest
Posts: n/a
 
      04-20-2012
On Fri, 20 Apr 2012 20:53:46 +0200, Bernd Nawothnig
<(E-Mail Removed)> wrote:

[snip]

>These implementation details should better be hidden and invisible for
>most cases. Let the compiler automatically detect and generate
>possible optimisations.


If you complicate things, the compiler then has to work to
decomplicate (optimise). Why not just keep it simple?

>A programming language should be as simple and orthogonal as possible.


One application of keeping it simple would be to use primitives
where possible -- since they are simpler than objects -- and only use
objects where they are needed.

Sincrely,

Gene Wirchenko
 
Reply With Quote
 
 
 
 
Thufir
Guest
Posts: n/a
 
      04-20-2012
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
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      04-20-2012
Lew <(E-Mail Removed)> 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
 
Reply With Quote
 
Jim Janney
Guest
Posts: n/a
 
      04-20-2012
rossum <(E-Mail Removed)> writes:

> On Fri, 20 Apr 2012 15:27:51 +0900, Tsukino Usagi <(E-Mail Removed)>
> 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
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      04-20-2012
On 4/20/2012 10:50 AM, Silvio Bierman wrote:
> On 04/20/2012 01:27 AM, Nasser M. Abbasi wrote:
>> According to
>>
>> "To Java SE 8, and Beyond! Simon Ritter Technology Evangelist, Oracle"
>>
>> (Google the string "To Java SE 8 and Beyond!" and click on
>> the PDF file, about the 5th link down the page)
>>
>> 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?
>>
>> For me, and I am no expert, I think it will be good to have
>> a consistent type model (everything is an object), but I am
>> worried that the performance will take a hit (computational finite
>> elements methods, large meshes, etc...), unless PC's and computers
>> will become 1000 times faster by the time JDK 10+ comes in few years
>> from now, which might be possible.
>>
>> Any one knows more information about this item?
>> Any truth to it? Do you think it will really happen?

>
> Scala already works this way. There is a common super type Any with
> subclasses AnyRef (akin Object) and AnyVal. The "primitives" reside
> under AnyVal.


Which is also the C#/.NET way.

Arne

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      04-20-2012
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

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      04-20-2012
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


 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      04-20-2012
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
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      04-20-2012
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Default primitive values from primitive Class<?> object. Daniel Pitts Java 7 10-23-2008 04:30 PM
Java reflection with primitive types Zach Java 2 06-08-2005 02:21 AM
Primitive vs. non-primitive l-value richardclay09@yahoo.co.uk C++ 7 05-09-2005 02:52 PM
Creating primitive data types from contents of String Jesper Sahner Java 13 11-16-2004 02:06 AM
Collections API for primitive types =?ISO-8859-1?Q?S=F8ren_Bak?= Java 0 08-27-2003 06:59 PM



Advertisments