www.digitalmars.com         C & C++   DMDScript  

D - Types

reply 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 !!
Jun 08 2002
next sibling parent reply "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 !!

Jun 08 2002
next sibling parent "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
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

 bolted.

 One of the (very) few good points about .NET is that they've done away

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


Jun 08 2002
prev sibling parent reply 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).
 

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");
Jun 08 2002
next sibling parent "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>

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


 bolted.

 One of the (very) few good points about .NET is that they've done away


 the asymmetry in Java between basic and object types, and done it
 efficiently (none of that hideous new Integer(i) nonsense).


 types act like user defined types. So 'int x;' creates a reference but

 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

 References to the type are just as familiar: 'MyClass * px;'.
 Initialization parameters are easily handled with the obvious 'MyClass

 I especially dislike things like:
     CheckedStackWithLogging  result_stack = new

Jun 09 2002
prev sibling next sibling parent "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>

 I notice that there are some languages that unify types by having the

 types act like user defined types. So 'int x;' creates a reference but

 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

 I especially dislike things like:
     CheckedStackWithLogging  result_stack = new

Agree. Sandor
Jun 11 2002
prev sibling parent "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

 types act like user defined types. So 'int x;' creates a reference but

 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

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

 I especially dislike things like:
     CheckedStackWithLogging  result_stack = new

Yes, that is clumsy.
Jun 14 2002
prev sibling parent 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.
Jun 08 2002