One of the only "practicalities" of Java is making arrays Objects.  I say
that it is a practicality because it is not very elegant, and I believe it
was
done to take advantage of the fact that arrays are already described by
a pointer, therefore they can be passed as parameters anywhere an
Object is required.

Making arrays an Object in D would allow strings 'char[]' to behave like
objects, but stay arrays.  This opens a little can of worms at the Object
end, because now you have a special type of Objects that are not
really objects, but it is so useful, I think it's worth the
"non-orthogonality"
in the language.

Has any thought been given to this?  I could not find discussion of this in the forum (although it is hard to search).

Thanks in advance,

Andres

At a time when compilers routinely do global flow optimization, I see no reason why the lowest level of values can't be treated the same semantically as every other type in the language.  In this way, arrays, ints, functions, and everything else should be Objects too.  For that matter, the language could also automatically move values to the stack when their lifetime is compile-time-deterministic.

Having this split between basic types and user-defined types just causes problems for the programmers, and doesn't save much if any work for the compiler vendors.

This has been discussed before, and it probably won't be changed at this late stage.  One can hope though.

Sean

Andres Rodriguez wrote:
| One of the only "practicalities" of Java is making arrays Objects.  I
| say that it is a practicality because it is not very elegant, and I
| believe it was
| done to take advantage of the fact that arrays are already described
| by
| a pointer, therefore they can be passed as parameters anywhere an
| Object is required.
|
| Making arrays an Object in D would allow strings 'char[]' to behave
| like objects, but stay arrays.  This opens a little can of worms at
| the Object end, because now you have a special type of Objects that
| are not
| really objects, but it is so useful, I think it's worth the
| "non-orthogonality"
| in the language.
|
| Has any thought been given to this?  I could not find discussion of
| this in the forum (although it is hard to search).

If everything was an Object (in D's current definition of Object) then it would have to have reference semantics. In particular ints and arrays would change behavior. For int the change would be drastic.

Templates should take care of the places where Java needs arrays to be
Objects (eg, a Vector of arrays). A simple wrapper (box/unbox) should do the
trick:

class ObjBox(T) {
  public T value;
  this(T x) { value = x; }
}

int
main()
{
  ObjBox!(int) x = new ObjBox!(int)(7);
  printf("%d\n", x.value);
  return 0;
}

-Ben

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bvjnc7$ote$1@digitaldaemon.com...
> At a time when compilers routinely do global flow optimization, I see no reason why the lowest level of values can't be treated the same
semantically
> as every other type in the language.  In this way, arrays, ints,
functions,
> and everything else should be Objects too.  For that matter, the language could also automatically move values to the stack when their lifetime is compile-time-deterministic.
>
> Having this split between basic types and user-defined types just causes problems for the programmers, and doesn't save much if any work for the compiler vendors.
>
> This has been discussed before, and it probably won't be changed at this late stage.  One can hope though.
>
> Sean
>
> Andres Rodriguez wrote:
> | One of the only "practicalities" of Java is making arrays Objects.  I
> | say that it is a practicality because it is not very elegant, and I
> | believe it was
> | done to take advantage of the fact that arrays are already described
> | by
> | a pointer, therefore they can be passed as parameters anywhere an
> | Object is required.
> |
> | Making arrays an Object in D would allow strings 'char[]' to behave
> | like objects, but stay arrays.  This opens a little can of worms at
> | the Object end, because now you have a special type of Objects that
> | are not
> | really objects, but it is so useful, I think it's worth the
> | "non-orthogonality"
> | in the language.
> |
> | Has any thought been given to this?  I could not find discussion of
> | this in the forum (although it is hard to search).
>
>

> If everything was an Object (in D's current definition of Object) then it would have to have reference semantics. In particular ints and arrays
would
> change behavior. For int the change would be drastic.

Indeed, if I understand D correctly, that is my point: arrays already have reference semantics.  And coming from Java I can tell you that you can almost do everything you want to do with object arrays and a little boxing here and there as you have shown.  Templates are much better of course, since they are much more efficient (time wise, and space wise it depends on the implementation) and compile-time type safe.

> Templates should take care of the places where Java needs arrays to be
> Objects (eg, a Vector of arrays). A simple wrapper (box/unbox) should do
the
> trick:

Agreed again.  The problem, I cannot seem to make templates work for me, see my earlier posting:

"How to instantiate a template? Bug?"

Thanks for your help,

Andres

"Andres Rodriguez" <rodriguez@ai.sri.com> wrote in message news:bvjsae$11g6$1@digitaldaemon.com...
>
> > If everything was an Object (in D's current definition of Object) then
it
> > would have to have reference semantics. In particular ints and arrays
> would
> > change behavior. For int the change would be drastic.
>
> Indeed, if I understand D correctly, that is my point: arrays already have reference semantics.

Arrays sort-of have reference semantics. An array (internally) is a struct of a length field and a pointer to the data. So the array data pointer has reference semantics but the array length has value semantics.

> And coming from Java I can tell you that you can
> almost do everything you want to do with object arrays and a little boxing
> here and there as you have shown.  Templates are much better of course,
> since they are much more efficient (time wise, and space wise it depends
on
> the implementation) and compile-time type safe.
>
> > Templates should take care of the places where Java needs arrays to be
> > Objects (eg, a Vector of arrays). A simple wrapper (box/unbox) should do
> the
> > trick:
>
> Agreed again.  The problem, I cannot seem to make templates work for me, see my earlier posting:
>
> "How to instantiate a template? Bug?"

Hmm. I don't know what is going wrong. The example I gave compiled fine on my machine.

> Thanks for your help,
>
> Andres
>
>

See, that's the problem.  Reference semantics should be in usage code, not an inherent property of Object.  C++ is proof that this is viable.

You should be able to subclass int just like you can subclass any other class.  I run into this in C++ alot.  I want to make a sort of streaming adapter template, with decorated objects that act like some other type but know how to stream themselves to and from binary files, but I cannot inherit from int, thus I have to break the illusion that my adapter *is* the kind of object and the user code has to go thru another level of indirection, cluttering up the entire program, *or* forcing me to make special cases for every single builtin type, of which there are many in C++, including pointers which can be to any user-defined type.  Needless to say, this makes decorating types in a generic manner an unnecessarily painful endeavor.

With modern day optimizing compilers, we *should* be able to treat every object semantically as if it were a heap object, and have the compiler "optimize" the object down onto the stack or into registers when it can safely do so.  And once we're treating all objects uniformly, we can stop having to explicitly specify that they go "on the heap" and just use objects in a simple way, letting the compiler take care of the details of where and how to allocate them.

As has been said by others many times, the language should be defined by its semantics.  Such semantics should be chosen so that efficient implementations can be made, without exposing the programmer to the gory details of such implementations.  The less explicit you force the programmers to be, the less opportunity they have to screw up, and the more opportunity the compiler vendor has to do things The Right Way.

Boxing/unboxing is an ugly implementation detail that has "escaped" and flutters about distracting programmers from the task at hand.  It is a sign of bad language design.

Likewise with memory allocation.  If you want programs that never leak, express memory allocation and deallocation in a way that can't possibly leak.  If you want programs that never crash, find ways to do things that can't possibly crash, (checking at runtime is a poor substitute for *proving* the program cannot misbehave).

This is one area where I fear Walter may actually be too stuck in the old-school mindset to innovate.  That doesn't mean D won't be a good language, it just means it won't be a cutting-edge language.  There is a revolution brewing, and I feel a language will have to be very solidly designed to survive.  Adding some patches to C won't be enough.

Sean

Ben Hinkle wrote:
| If everything was an Object (in D's current definition of Object)
| then it would have to have reference semantics. In particular ints
| and arrays would change behavior. For int the change would be drastic.
|
| Templates should take care of the places where Java needs arrays to be
| Objects (eg, a Vector of arrays). A simple wrapper (box/unbox) should
| do the trick:
|
| class ObjBox(T) {
|   public T value;
|   this(T x) { value = x; }
| }
|
| int
| main()
| {
|   ObjBox!(int) x = new ObjBox!(int)(7);
|   printf("%d\n", x.value);
|   return 0;
| }
|
| -Ben
|
| "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message
| news:bvjnc7$ote$1@digitaldaemon.com...
|| At a time when compilers routinely do global flow optimization, I
|| see no reason why the lowest level of values can't be treated the
|| same semantically as every other type in the language.  In this way,
|| arrays, ints, functions, and everything else should be Objects too.
|| For that matter, the language could also automatically move values
|| to the stack when their lifetime is compile-time-deterministic.
||
|| Having this split between basic types and user-defined types just
|| causes problems for the programmers, and doesn't save much if any
|| work for the compiler vendors.
||
|| This has been discussed before, and it probably won't be changed at
|| this late stage.  One can hope though.
||
|| Sean
||
|| Andres Rodriguez wrote:
||| One of the only "practicalities" of Java is making arrays Objects.
||| I say that it is a practicality because it is not very elegant, and
||| I believe it was
||| done to take advantage of the fact that arrays are already described
||| by
||| a pointer, therefore they can be passed as parameters anywhere an
||| Object is required.
|||
||| Making arrays an Object in D would allow strings 'char[]' to behave
||| like objects, but stay arrays.  This opens a little can of worms at
||| the Object end, because now you have a special type of Objects that
||| are not
||| really objects, but it is so useful, I think it's worth the
||| "non-orthogonality"
||| in the language.
|||
||| Has any thought been given to this?  I could not find discussion of
||| this in the forum (although it is hard to search).

> Arrays sort-of have reference semantics. An array (internally) is a struct of a length field and a pointer to the data. So the array data pointer has reference semantics but the array length has value semantics.

So making arrays objects will not be the cleanest of all solutions, but a
practical and useful one.  As I said in my original posting, it's a
compromise,
adding something somewhat ugly, because it's terribly useful.  From the
compiler point of view I think it's pretty straight forward.

> Hmm. I don't know what is going wrong. The example I gave compiled fine on my machine.

The example you gave does not make use of the template type, it's
very simple template code.  If I am trying to build a more generic template
library, I am going to want to do more complex things (as in the example
I gave).

Cheers and thank for your answers,

Andres

i hope walter reads this.

the half-ref,half-copy semantic of arrays can be rather irritating, and lead to "D is strange" views just as C has with its only static arrays that lead to tons of overflow bugs today..

currently, an array is just

struct array {
    type* data;
    uint size;
}

how about this?

struct Array {
    uint size;
    type[] data; // this is an extension of c++ existing in vc6 and 7
}

typedef Array^ array; // the ^ indicates its a gc pointer, as in c++.net 2.0
(withbey)

heh.. without tons of microsoft c++ extensions, what i think is not expressable in c really..

in simple words:

just put the size at the beginning of the actual array, instead beside the pointer. 99% of the time, where you need to access the size, you will access the array as well anyways, so the indirect pointer => cache issues are negitible.

the gain would be, an array would get 100% reference semantic. this would be much more understandable to all users.

arrays would then be objects.

any reasons why not? (except the, as said, negitible performance issue)

oh, and static arrays don't have problems with that as well..


so

allocator(type[]) = type[] (uint count) {
    void* data = malloc(uint.size + count*type.size);
    *(uint*)data = count;
    gc.takeCareOfThisHehe(data);
    return cast(type[])data;
}


something like this. it's very late, and i have to get up very early.. i hope you get the idea.

it would be really helpful, i guess.

"Andres Rodriguez" <rodriguez@ai.sri.com> schrieb im Newsbeitrag news:bvjffn$bu2$1@digitaldaemon.com...
> One of the only "practicalities" of Java is making arrays Objects.  I say
> that it is a practicality because it is not very elegant, and I believe it
> was
> done to take advantage of the fact that arrays are already described by
> a pointer, therefore they can be passed as parameters anywhere an
> Object is required.
>
> Making arrays an Object in D would allow strings 'char[]' to behave like
> objects, but stay arrays.  This opens a little can of worms at the Object
> end, because now you have a special type of Objects that are not
> really objects, but it is so useful, I think it's worth the
> "non-orthogonality"
> in the language.
>
> Has any thought been given to this?  I could not find discussion of this
in
> the forum (although it is hard to search).
>
> Thanks in advance,
>
> Andres
>
>

> just put the size at the beginning of the actual array, instead beside the
> pointer. 99% of the time, where you need to access the size, you will access
> the array as well anyways, so the indirect pointer => cache issues are
> negitible.


You can't do that unless you always want to copy the array.

char[] foo = "hello";
char[] bar = foo[0 .. 2];

Instead of having a slice in foo, you have to allocate memory so that the length can be stored before it.
The nature of a dynamic array is to just have a slice of any old memory. If you want to always copy the values, create your own type (class).

"Andres Rodriguez" <rodriguez@ai.sri.com> wrote in message news:bvjffn$bu2$1@digitaldaemon.com...
> One of the only "practicalities" of Java is making arrays Objects.  I say
> that it is a practicality because it is not very elegant, and I believe it
> was
> done to take advantage of the fact that arrays are already described by
> a pointer, therefore they can be passed as parameters anywhere an
> Object is required.
>
> Making arrays an Object in D would allow strings 'char[]' to behave like
> objects, but stay arrays.  This opens a little can of worms at the Object
> end, because now you have a special type of Objects that are not
> really objects, but it is so useful, I think it's worth the
> "non-orthogonality"
> in the language.
>
> Has any thought been given to this?  I could not find discussion of this
in
> the forum (although it is hard to search).

Giving arrays Object semantics like Java would have some repercussions:
1) Each array would need to have a virtual table pointer added and a slot
for a monitor.
2) I doubt it could be made to interact cleanly with C style arrays.
3) If (1) is not done, the alternative is for every Object reference, code
must be executed to attempt to distinguish an array from an Object.