This is in the 'that boat has sailed' category, but why is it that.
    int  X;
creates an instance of type 'int', while
    File X;
     X = new  File;
creates a an instance  of type 'File', and

    int * pX;
creates a reference to an object  of type 'int' but
    File * pX;
is illegal (I think)?

I realize that this is 'standard' syntax in the OO world, but I have always been annoyed by the asymmetry.

Whats wrong with:
    File F;       //  F is an instance of a 'File', with members
                    //  initialized to default values
    File * pF;   // pF is an unititialized reference to a file

I also realize that simple types and user-defined types are slightly different, but shouldn't a language emphasize their similarities rather than their differences?

Does 'File F' create an instance or a reference? No way to tell !!

It's not a bad point, although I think you're correct in that the horse has bolted.

One of the (very) few good points about .NET is that they've done away with
the asymmetry in Java between basic and object types, and done it
efficiently (none of that hideous new Integer(i) nonsense).

Walter, I wonder what your opinions are about making a similar code-time (obviously optimised away at compile time to the current implementation)

"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1023549538@bose...
> This is in the 'that boat has sailed' category, but why is it that.
>     int  X;
> creates an instance of type 'int', while
>     File X;
>      X = new  File;
> creates a an instance  of type 'File', and
>
>     int * pX;
> creates a reference to an object  of type 'int' but
>     File * pX;
> is illegal (I think)?
>
> I realize that this is 'standard' syntax in the OO world, but I have always been annoyed by the asymmetry.
>
> Whats wrong with:
>     File F;       //  F is an instance of a 'File', with members
>                     //  initialized to default values
>     File * pF;   // pF is an unititialized reference to a file
>
> I also realize that simple types and user-defined types are slightly different, but shouldn't a language emphasize their similarities rather than their differences?
>
> Does 'File F' create an instance or a reference? No way to tell !!
>
>
>

[How strange. This sent without my requesting the incomparable Outlook Express to do so. ]

Was not going to bother to send, but now that I have done, Walter I wonder what your opinions would be about having a similar consistency between built-in and user-defined types as C# (and also having the same compiled efficiencies for built-ins)?

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:adu4bg$1id7$2@digitaldaemon.com...
> It's not a bad point, although I think you're correct in that the horse
has
> bolted.
>
> One of the (very) few good points about .NET is that they've done away
with
> the asymmetry in Java between basic and object types, and done it
> efficiently (none of that hideous new Integer(i) nonsense).
>
> Walter, I wonder what your opinions are about making a similar code-time (obviously optimised away at compile time to the current implementation)
>
> "Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1023549538@bose...
> > This is in the 'that boat has sailed' category, but why is it that.
> >     int  X;
> > creates an instance of type 'int', while
> >     File X;
> >      X = new  File;
> > creates a an instance  of type 'File', and
> >
> >     int * pX;
> > creates a reference to an object  of type 'int' but
> >     File * pX;
> > is illegal (I think)?
> >
> > I realize that this is 'standard' syntax in the OO world, but I have always been annoyed by the asymmetry.
> >
> > Whats wrong with:
> >     File F;       //  F is an instance of a 'File', with members
> >                     //  initialized to default values
> >     File * pF;   // pF is an unititialized reference to a file
> >
> > I also realize that simple types and user-defined types are slightly different, but shouldn't a language emphasize their similarities rather than their differences?
> >
> > Does 'File F' create an instance or a reference? No way to tell !!
> >
> >
> >
>
>
>
>

Karl Bochert <kbochert@ix.netcom.com> wrote in news:1103_1023549538@bose:

> This is in the 'that boat has sailed' category, but why is it that.
>     int  X;
> creates an instance of type 'int', while
>     File X;
>      X = new  File;
> creates a an instance  of type 'File', and

int X;

X can have a range of values that are integers but it
is initialized to 0.

File Y;

Y can have a range of File object instances but it
is initialized to the "null" object.

If you wanted X to start out with a different value
you would write.

int X = 5;

In turn if you want to initialize Y to be a non
null file instance you would write.

File Y = new File;

I admit that failing to initialize object references
is a common issue but I dont see the syntax as being
inconsistant.

On Sun, 9 Jun 2002 09:39:12 +1000, "Matthew Wilson" <dmd@synesis.com.au> wrote:
> It's not a bad point, although I think you're correct in that the horse has bolted.
> 
> One of the (very) few good points about .NET is that they've done away with
> the asymmetry in Java between basic and object types, and done it
> efficiently (none of that hideous new Integer(i) nonsense).
> 
I notice that there are some languages that unify types by having the built-in
types act like user defined types. So 'int x;' creates a reference but does
not allocate any storage, just like 'MyClass x;'
As an old C programmer, I find this quite disturbing.
 I am not aware of any languages that do it the other way around: make
 the user-defined types act like the built-ins we all know and love.
Then 'MyClass x;' creates an actual instace of the type, with storage
initialized to default values. The call to new() is hidden (just like with int).
References to the type are just as familiar: 'MyClass * px;'.
Initialization parameters are easily handled with the obvious 'MyClass x(1,2);'

I especially dislike things like:
    CheckedStackWithLogging  result_stack = new  CheckedStackWithLogging("E:\project\logfile");

That's like function call syntax.  And dammit languages are heading in the direction that you compute with objects and not functions.  And the more concise that syntax is the better because it's the stuff that clogs up programs and makes them icky.  I want to have as much implicit behavior possible so I can get the language to do work for me.  I love builtins; stack based programming is great.  I wish everything were an array or a stack it's so simple.  The heap is a complicated monster with great unpredictability.  Surely someone will think of a way to do really uber nice memory management.  Some kind of hybrid data structure between a heap and a stack, sort of like a heap managed by type and fixed cluster size organized as hierarchical clusters of clusters plus a pointer to the next cluster.  So you could somehow guarantee the block quantity of allocations of these kinds of objects.  You'd need for 31 objects, 32 objects worth of space where the extra slot is used to store the "next" cluster pointer (or "this" cluster size), and a 32-bit mask of which of the slots are "in use".  When it's full it makes another group of up to 32 or more and forms heaps of chains.  It's pretty easy to control the fixed size of a chain to guarantee nice memory packing of related objects.  The GC could take advantage of this.

But that's getting beside the point the point is it's much nicer to be able to work with objects the way you do on the stack, but doggone it that doesn't let you pass objects thru functions and still be able to control or observe what the function does with it (such as store a pointer to it for later use; in other words can't easily write native quality data structures like container classes that work like a "front" for a resource because that lets you fool the system.  A system like I've been talking about would be fooled by the same kind of things that fool Garbage Collectors.)  I like being able to make foolproof systems.

I wish Walter were more into tracing what's going on re: data flow in the function;  I realize that's the hardest part of writing an optimizing compiler but he can do that;  it's also the kind of thing that helps people make clever tools that do lots of work automagically behind your back.  The kind of things that makes fresh-off-the-boat C programmers shiver with fear about;  you've seen them, complaining about how it's too much work to step through the inlined template code in the debugger.  ;)  I finally found a macro thingy for VC++ that fixes that problem for the most part so I'm happy about that part now too hehe.

Well template programming almost requires the language to unify UDT syntactically at least.  And it's very close to metaprogramming.  A language that can native execute strings containing valid D code would be cool.  ;) But that may only be possible for small tight languages that are easy to parse and such.

Another thing I would want is for invariants to be able to be enforced externally by explicitly telling the compiler to "insert this code or exception or compile time error" whenever it sees a write to this object or read from it.  Useful debugging and software engineering type stuff.

Sean

"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1023604027@bose...
> On Sun, 9 Jun 2002 09:39:12 +1000, "Matthew Wilson" <dmd@synesis.com.au>
wrote:
> > It's not a bad point, although I think you're correct in that the horse
has
> > bolted.
> >
> > One of the (very) few good points about .NET is that they've done away
with
> > the asymmetry in Java between basic and object types, and done it
> > efficiently (none of that hideous new Integer(i) nonsense).
> >
> I notice that there are some languages that unify types by having the
built-in
> types act like user defined types. So 'int x;' creates a reference but
does
> not allocate any storage, just like 'MyClass x;'
> As an old C programmer, I find this quite disturbing.
>  I am not aware of any languages that do it the other way around: make
>  the user-defined types act like the built-ins we all know and love.
> Then 'MyClass x;' creates an actual instace of the type, with storage
> initialized to default values. The call to new() is hidden (just like with
int).
> References to the type are just as familiar: 'MyClass * px;'. Initialization parameters are easily handled with the obvious 'MyClass
x(1,2);'
>
> I especially dislike things like:
>     CheckedStackWithLogging  result_stack = new
CheckedStackWithLogging("E:\project\logfile");

"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1023604027@bose...
> On Sun, 9 Jun 2002 09:39:12 +1000, "Matthew Wilson" <dmd@synesis.com.au>
wrote:
> I notice that there are some languages that unify types by having the
built-in
> types act like user defined types. So 'int x;' creates a reference but
does
> not allocate any storage, just like 'MyClass x;'
> As an old C programmer, I find this quite disturbing.
>  I am not aware of any languages that do it the other way around: make
>  the user-defined types act like the built-ins we all know and love.

Hell, it is C++. You seem to be whining for a syntax of C++.

> Then 'MyClass x;' creates an actual instace of the type, with storage
> initialized to default values.
> The call to new() is hidden (just like with int).
> References to the type are just as familiar: 'MyClass * px;'.
> Initialization parameters are easily handled with the obvious 'MyClass
x(1,2);'
>
> I especially dislike things like:
>     CheckedStackWithLogging  result_stack = new
CheckedStackWithLogging("E:\project\logfile");

Agree.

Sandor

"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1023604027@bose...
> I notice that there are some languages that unify types by having the
built-in
> types act like user defined types. So 'int x;' creates a reference but
does
> not allocate any storage, just like 'MyClass x;'
> As an old C programmer, I find this quite disturbing.
>  I am not aware of any languages that do it the other way around: make
>  the user-defined types act like the built-ins we all know and love.
> Then 'MyClass x;' creates an actual instace of the type, with storage
> initialized to default values. The call to new() is hidden (just like with
int).

But references initialized to null are very useful.

> References to the type are just as familiar: 'MyClass * px;'. Initialization parameters are easily handled with the obvious 'MyClass
x(1,2);'



> I especially dislike things like:
>     CheckedStackWithLogging  result_stack = new
CheckedStackWithLogging("E:\project\logfile");

Yes, that is clumsy.