• Karl Bochert (20/20) Jun 08 2002 This is in the 'that boat has sailed' category, but why is it that.
• Matthew Wilson (9/29) Jun 08 2002 It's not a bad point, although I think you're correct in that the horse ...
• Matthew Wilson (10/47) Jun 08 2002 [How strange. This sent without my requesting the incomparable Outlook
• Karl Bochert (13/20) Jun 08 2002 I notice that there are some languages that unify types by having the bu...
• Sean L. Palmer (56/76) Jun 09 2002 That's like function call syntax. And dammit languages are heading in t...
• Sandor Hojtsy (10/24) Jun 11 2002 wrote:
• Walter (9/21) Jun 14 2002 built-in
• Patrick Down (16/22) Jun 08 2002 int X;

Karl Bochert <kbochert ix.netcom.com> writes:

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 !!

"Matthew Wilson" <dmd synesis.com.au> writes:

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 !!

"Matthew Wilson" <dmd synesis.com.au> writes:

[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

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> writes:

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");

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

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");

"Sandor Hojtsy" <hojtsy index.hu> writes:

"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

"Walter" <walter digitalmars.com> writes:

"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.

Patrick Down <pat codemoon.com> writes:

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.