A question, I'm not sure if it's been asked:

Is Auto-Boxing a Good Thing or a Bad Thing ?
And if it's good, should be available in D ?


* With boxing, you can write stuff like:

    int i;
    Integer o = i;

And have the compiler create an object.


* Without boxing, you instead just get a type error:

"cannot implicitly convert expression i of type int to Integer"

And have to spell the object creation out for it:

    Integer o = new Integer(i);

Makes it more readily apparent that a new object is
being created, but takes a couple of extra keystrokes ?


Would it be good to have the first code map into the second ?
(so that when you assign a primitive to an object, it "boxes")

Note that D already supports auto-*un*boxing, with opCast():

    i = cast(int) o;

Trying to do same cast thing in the other direction, cast(Integer),
stuffs the address i in the reference and it goes South from there.


What do you think?
--anders


PS. The class code was:

> class Integer
> {
>   public:
>     this(int i) { value = i; }
>     int opCast() { return value; }
>   private:
>     int value;
> }

Anders F Björklund wrote:

> A question, I'm not sure if it's been asked:
> 
> Is Auto-Boxing a Good Thing or a Bad Thing ?
> And if it's good, should be available in D ?

Before we can possibly have this, we'd need standard wrapper classes for the various types.  But what do we need standard wrapper classes for?

<snip>
> Note that D already supports auto-*un*boxing, with opCast():
> 
>     i = cast(int) o;
<snip>

That isn't *auto*-unboxing.  It's using the cast operator to manually unbox.

Stewart.

Anders F Björklund wrote:
> A question, I'm not sure if it's been asked:
> 
> Is Auto-Boxing a Good Thing or a Bad Thing ?
> And if it's good, should be available in D ?

What would you use it for?

The only time I have ever wanted to do this is when stuffing primitive types in an untyped C#/Java collection.  This leads me to believe that automatic boxing is a cludge over a horrible, crippling weakness and not a feature. :)

 -- andy

Stewart Gordon wrote:

> Before we can possibly have this, we'd need standard wrapper classes for the various types.  But what do we need standard wrapper classes for?

I'm not sure. The issue just arose when discussing boolean and strings?

In Java, they're just used to pass around Objects to the Collection API
and other such things. But I guess you could just as well just use the
primitive types and instead apply templating ? Probably faster, too...

> That isn't *auto*-unboxing. It's using the cast operator to manually unbox.

Right. Got my terminology a little confused there. Unboxing, not auto.
So I guess using a primitive type constructor is manually boxing then?

It's not that I miss all those Java objects for Strings and Arrays much.

--anders

Andy Friesen wrote:

>> Is Auto-Boxing a Good Thing or a Bad Thing ?

> The only time I have ever wanted to do this is when stuffing primitive types in an untyped C#/Java collection.  This leads me to believe that automatic boxing is a cludge over a horrible, crippling weakness and not a feature. :)

Yeah, it does seem that way. So far the most opinions
have been that auto-boxing creates a lot of wasteful
objects, especially if you *mix* classes and primitives.
And that auto-unboxing creates some troubles will null,
and with checks for identity and also with assignments...
So it does seem that it's more or less just a kludge ?

And of course, it's a nice little marketing buzzword.

--anders

Anders F Björklund wrote:
<snip>
> In Java, they're just used to pass around Objects to the Collection API
> and other such things. But I guess you could just as well just use the
> primitive types and instead apply templating ? Probably faster, too...

AIUI the main reason for wrapper classes in Java was so that they can be put into containers, in a language that lacks templates.

Now Java 1.5 has templates, but only classes are allowed as parameter types.  I'm guessing that this is down to some implementation constraint in how the Java VM works.  The wrapper classes remain both to support legacy code and for use in the new templates.

If these wrapper classes weren't needed for templates, then there probably wouldn't have been any point in inventing auto-(un)boxing this late in Java's life.

OTOH, Java allows primitive types to be template parameters, and so chances are we don't really need wrapper classes.

<snip>
> Right. Got my terminology a little confused there. Unboxing, not auto.
> So I guess using a primitive type constructor is manually boxing then?
<snip>

Primitive type constructor?  You mean wrapper class constructor?

Stewart.

Stewart Gordon wrote:

> Primitive type constructor?  You mean wrapper class constructor?

Yeah, "wrapper class constructor that takes a primitive type argument".

> class Integer
> {
>   public:
>     this(int i) { value = i; }

Integer o = new Integer(i);

--anders

Stewart Gordon wrote:

> OTOH, Java allows primitive types to be template parameters, and so chances are we don't really need wrapper classes.

I think you meant "D" instead of Java here ? If you did, I agree :-)
Wrapper classes are evil. Especially when used for things like String.

If everything should be an object, there are plenty of other languages.
(Smalltalk, Objective-C, Java, Ruby). No wrapper classes => No boxing.

--anders

Correction:
> If everything should be an object, there are plenty of other languages.
> (Smalltalk, Objective-C, Java, Ruby). No wrapper classes => No boxing.

Ehrm, Objective-C is just "C and Smalltalk". I meant C# and Python :-)

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:ckp37m$2clu$2@digitaldaemon.com...
> Stewart Gordon wrote:
>
>> OTOH, Java allows primitive types to be template parameters, and so chances are we don't really need wrapper classes.
>
> I think you meant "D" instead of Java here ? If you did, I agree :-) Wrapper classes are evil. Especially when used for things like String.

IMO, Walter's single greatest point of genius vision was in the definition of slices.

As with so many other things from D, I'm busy at the moment implementing slices for C++. Without garbage collection it is, as you can imagine, somewhat more difficult than it is in D.

:-)