www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Classes derived from basic type ?

reply Vladimir <Vladimir_member pathlink.com> writes:
Hello All ! 
I'm just studying D and have been impressed with it's features. 
But some of its I can't understand, for example, presence of .sort method. 
I'm wondering, if D have so compicated base types, which in most senses looks  
exactly like classes, why can't I derive my own classes from it ? Is would be 
very useful in meny cases, and I'm remembering meny uses of it for example in 
python.
Mar 30 2005
next sibling parent "Carlos Santander B." <csantander619 gmail.com> writes:
Vladimir wrote:

 Hello All ! 
 I'm just studying D and have been impressed with it's features. 
 But some of its I can't understand, for example, presence of .sort method. 
 I'm wondering, if D have so compicated base types, which in most senses looks  
 exactly like classes, why can't I derive my own classes from it ? Is would be 
 very useful in meny cases, and I'm remembering meny uses of it for example in 
 python. 
 
 
 


There's no way to do it in D. In D (just like in many other languages) 
not everything is an object.

_______________________
Carlos Santander Bernal
Mar 30 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
 But some of its I can't understand, for example, presence of .sort
 method. I'm wondering, if D have so compicated base types, which in
 most senses looks exactly like classes, why can't I derive my own
 classes from it ? Is would be very useful in meny cases, and I'm
 remembering meny uses of it for example in python.


While we're at subtleties in a language, this is a golden example of such!

A person new to D, looks at things like arrays, and sees .sort methods 
and other stuff. This leads -- most naturally -- one to think that we 
have classes here.

Skimming the documentation while believing this, only makes a person 
confused: ehh, how come there's no proper documentation for these 
classes, where are all these methods, why can't I derive, etc.

One does not immediately see that there _are_ no classes here. One only 
somehow (especially, this  being a new language) assumes, that we then 
may have some new philosophy or new kinds of classes in _this_ language.

Such significantly slows down the process of learning. With any bad 
luck, such misconceptions stay uncorrected for a longer time, and quite 
a lot learned during that period, gets its fundaments wrong in one's 
head. In other words, the reader is entertaining a mental model of the 
language that is not congruent with that of the developers', which leads 
to unnecessarily complicated mental structures and gymnastics, when 
trying to "understand" (or even just learn by heart) the properties of 
the language.

Some of these may be very hard to undo, even after one has been told 
that the original concept was wrong. Even for smart persons, this often 
happens only after having visited each particular "collateral 
misconception" separately -- in spite of the fact that with reason one 
should be able to let the correction "cascade" through all the cases. 
Old and rooted (mis)conceptions don't die that easily.

(Ex. Some people have a hard time quickly using the right name of many 
months late in the year.)

Even if one is able to get the D facts right at the end, what really 
does stay, is a belief that this is a labyrinthine and complicated 
language. And full of trip stones. -- Yet another misconception in itself.

----

So, if something looks like A, it should be A and not B.

Convenience shortcuts and such are bad *if* they hamper clarity of vision.

What I am saying is: in the future we should avoid conveniences that to 
the uninitiated look like something they aren't.
Apr 09 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <42581AE6.5070103 nospam.org>, Georg Wrede says...

 But some of its I can't understand, for example, presence of .sort
 method. I'm wondering, if D have so compicated base types, which in
 most senses looks exactly like classes, why can't I derive my own
 classes from it ? Is would be very useful in meny cases, and I'm
 remembering meny uses of it for example in python.


While we're at subtleties in a language, this is a golden example of such!

A person new to D, looks at things like arrays, and sees .sort methods 
and other stuff. This leads -- most naturally -- one to think that we 
have classes here.

Skimming the documentation while believing this, only makes a person 
confused: ehh, how come there's no proper documentation for these 
classes, where are all these methods, why can't I derive, etc.


I agree.  And the lack of consistency between arrays and primitive types in this
respect is IMO a bad thing.   I would prefer if any function:

R func( X val, ... )

Could be called normally:

X val;
func( val, a, b, c );

Or dotted:

val.func( a, b, c );

Even better would be if the compiler saw a class derived from a primitive type:

class X : int {}

then the primitive type would be interpreted as a wrapper class exposing all the
usual operator overloads and such.

But this second bit isn't strictly necessary as it would be easy enough to
define a template class for this purpose:










So primitives could be inherited like so:

class MyInt : ClassOf!(int) {}

In fact I think I may define a class like this for Ares just to have it around.


Sean
Apr 09 2005
next sibling parent reply "Kris" <fu bar.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:d39j88$2d2q$1 digitaldaemon.com...

 In article <42581AE6.5070103 nospam.org>, Georg Wrede says...

 But some of its I can't understand, for example, presence of .sort
 method. I'm wondering, if D have so compicated base types, which in
 most senses looks exactly like classes, why can't I derive my own
 classes from it ? Is would be very useful in meny cases, and I'm
 remembering meny uses of it for example in python.


While we're at subtleties in a language, this is a golden example of




such!

A person new to D, looks at things like arrays, and sees .sort methods
and other stuff. This leads -- most naturally -- one to think that we
have classes here.

Skimming the documentation while believing this, only makes a person
confused: ehh, how come there's no proper documentation for these
classes, where are all these methods, why can't I derive, etc.


 I agree.  And the lack of consistency between arrays and primitive types


in this

 respect is IMO a bad thing.   I would prefer if any function:

 R func( X val, ... )

 Could be called normally:

 X val;
 func( val, a, b, c );

 Or dotted:

 val.func( a, b, c );

 Even better would be if the compiler saw a class derived from a primitive


type:

 class X : int {}

 then the primitive type would be interpreted as a wrapper class exposing


all the

 usual operator overloads and such.

 But this second bit isn't strictly necessary as it would be easy enough to
 define a template class for this purpose:










 So primitives could be inherited like so:

 class MyInt : ClassOf!(int) {}

 In fact I think I may define a class like this for Ares just to have it


around.

 Sean


It would indeed be very nice were D to cleanly support an ability for adding

once noted)

- Kris
Apr 09 2005
parent reply pragma <pragma_member pathlink.com> writes:
In article <d39pkv$313k$1 digitaldaemon.com>, Kris says...

"Sean Kelly" <sean f4.ca> wrote in message

 class MyInt : ClassOf!(int) {}

 In fact I think I may define a class like this for Ares just to have it


around.

 Sean


It would indeed be very nice were D to cleanly support an ability for adding

once noted)


Would something like this work?

http://www.prowiki.org/wiki4d/wiki.cgi?Typedef-Block

- EricAnderton at yahoo
Apr 11 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <d3e93k$2tco$1 digitaldaemon.com>, pragma says...

In article <d39pkv$313k$1 digitaldaemon.com>, Kris says...

"Sean Kelly" <sean f4.ca> wrote in message

 class MyInt : ClassOf!(int) {}

 In fact I think I may define a class like this for Ares just to have it


around.

 Sean


It would indeed be very nice were D to cleanly support an ability for adding

once noted)


Would something like this work?

http://www.prowiki.org/wiki4d/wiki.cgi?Typedef-Block


Yes :)  This is an excellent proposal for how to implement this feature.


Sean
Apr 11 2005
prev sibling parent reply Vladimir <kv11111 mail.ru> writes:
pragma wrote:

 Would something like this work?
 http://www.prowiki.org/wiki4d/wiki.cgi?Typedef-Block


It seems good, but in my opinion typedef-blocks and structs are too similar
to exists as different constructs.
If we allow struct inheritance by means of just adding base struct members
to the front of child struct, and allow struct inheritance from basic types
it would solve the problem.
Casting child struct to base struct can be allowed, but all struct methods
must be treated as non-virtual, so we can keep compitability with C
structs.

Examples:
// analog for typedef int MyInt
struct MyInt: int {}

//  ( super is just shortcat for cast(int*)this )
struct SmartInt: int {
    public SmartInt opPos(){ // change opPos into an absolute-value operator
        if(*super < 0) return(-*this);
        return(*this);
    }
}

// static array
//  ( using template syntax )
struct AutoSumIntArray(N): int[N] {
    private int _sum = 0;
    int sum() { return _sum; }
    int opIndexAssign(int val, int idx) {
        _sum -= (*super)[idx];
        (*super)[idx] = val;
        _sum += (*super)[idx];
    }
    int opSliceAssign(...) { ... }
}

// dynamic array
//   must use class syntax becouse of reference semantic
class BoundedIntDynArray: int[] {
    int bound = 100;
    this(int l) {
        if(l > bound) assert(0);
        super(l);
    }
    void length(int l) {
        if(l > bound) assert(0);
        super.length = l;
    }
}

-- 
          Vladimir
Apr 12 2005
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <d3g3c6$2576$1 digitaldaemon.com>, Vladimir says...

pragma wrote:

 Would something like this work?
 http://www.prowiki.org/wiki4d/wiki.cgi?Typedef-Block


It seems good, but in my opinion typedef-blocks and structs are too similar
to exists as different constructs.
If we allow struct inheritance by means of just adding base struct members
to the front of child struct, and allow struct inheritance from basic types
it would solve the problem.
Casting child struct to base struct can be allowed, but all struct methods
must be treated as non-virtual, so we can keep compitability with C
structs.

Examples:
// analog for typedef int MyInt
struct MyInt: int {}

//  ( super is just shortcat for cast(int*)this )
struct SmartInt: int {
    public SmartInt opPos(){ // change opPos into an absolute-value operator
        if(*super < 0) return(-*this);
        return(*this);
    }
}

// static array
//  ( using template syntax )
struct AutoSumIntArray(N): int[N] {
    private int _sum = 0;
    int sum() { return _sum; }
    int opIndexAssign(int val, int idx) {
        _sum -= (*super)[idx];
        (*super)[idx] = val;
        _sum += (*super)[idx];
    }
    int opSliceAssign(...) { ... }
}

// dynamic array
//   must use class syntax becouse of reference semantic
class BoundedIntDynArray: int[] {
    int bound = 100;
    this(int l) {
        if(l > bound) assert(0);
        super(l);
    }
    void length(int l) {
        if(l > bound) assert(0);
        super.length = l;
    }
}

-- 
          Vladimir


This could work, but the only problem is that you loose implicit casting since
the memory footprint of some of your examples are not the same as the underlying
type.  But then again, you'd have to use the typedef explicitly (casting and
whatnot) to get the functionality you need, so I guess there's little
difference.  This way you get shorthand-templating for 'free' which is a huge
plus. (use of 'super' is nice too)

As long as you get to inherit the base scalar's operators and properties, I
honestly don't care which style makes it through.  Its too useful a construct
not to have. :)


- EricAnderton at yahoo
Apr 12 2005
parent Vladimir <kv11111 mail.ru> writes:
pragma wrote:

Examples:
// analog for typedef int MyInt
struct MyInt: int {}

//  ( super is just shortcat for cast(int*)this )
struct SmartInt: int {
    public SmartInt opPos(){ // change opPos into an absolute-value
    operator
        if(*super < 0) return(-*this);
        return(*this);
    }
}

// static array
//  ( using template syntax )
struct AutoSumIntArray(N): int[N] {
    private int _sum = 0;
    int sum() { return _sum; }
    int opIndexAssign(int val, int idx) {
        _sum -= (*super)[idx];
        (*super)[idx] = val;
        _sum += (*super)[idx];
    }
    int opSliceAssign(...) { ... }
}

// dynamic array
//   must use class syntax becouse of reference semantic
class BoundedIntDynArray: int[] {
    int bound = 100;
    this(int l) {
        if(l > bound) assert(0);
        super(l);
    }
    void length(int l) {
        if(l > bound) assert(0);
        super.length = l;
    }
}


 
 This could work, but the only problem is that you loose implicit casting
 since the memory footprint of some of your examples are not the same as
 the underlying


Only if I add new data members.


 type.  But then again, you'd have to use the typedef explicitly (casting
 and whatnot) to get the functionality you need, so I guess there's little
 difference.  This way you get shorthand-templating for 'free' which is a
 huge plus. (use of 'super' is nice too)
 
 As long as you get to inherit the base scalar's operators and properties,
 I
 honestly don't care which style makes it through.  Its too useful a
 construct not to have. :)


Absolutely agree.

-- 
          Vladimir
Apr 13 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Vladimir wrote:
<snip>

 If we allow struct inheritance by means of just adding base struct members
 to the front of child struct, and allow struct inheritance from basic types
 it would solve the problem.
 Casting child struct to base struct can be allowed, but all struct methods
 must be treated as non-virtual, so we can keep compitability with C
 structs.
 
 Examples:
 // analog for typedef int MyInt
 struct MyInt: int {}
 
 //  ( super is just shortcat for cast(int*)this )
 struct SmartInt: int {
     public SmartInt opPos(){ // change opPos into an absolute-value operator
         if(*super < 0) return(-*this);
         return(*this);
     }
 }


<snip>

This is like an idea that I thought of, though on existing 
structs/unions rather than primitive types.

Under my idea, the derived type would be a union rather than a struct. 
This is because with the way D works, it doesn't make so much sense to 
add data members - since structs have value semantics, increasing the 
size means that it isn't really a value of the base type anymore.  OTOH 
it does make a bit of sense to add methods and/or views of the data to 
an existing struct (such as one defined in an external API).

But I guess this idea could work on built-in types as well....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Apr 20 2005
parent Vladimir <kv11111 mail.ru> writes:
Stewart Gordon wrote:

 Vladimir wrote:
 <snip>

 If we allow struct inheritance by means of just adding base struct
 members to the front of child struct, and allow struct inheritance from
 basic types it would solve the problem.
 Casting child struct to base struct can be allowed, but all struct
 methods must be treated as non-virtual, so we can keep compitability with
 C structs.
 
 Examples:
 // analog for typedef int MyInt
 struct MyInt: int {}
 
 //  ( super is just shortcat for cast(int*)this )
 struct SmartInt: int {
     public SmartInt opPos(){ // change opPos into an absolute-value
     operator
         if(*super < 0) return(-*this);
         return(*this);
     }
 }


 <snip>
 
 This is like an idea that I thought of, though on existing
 structs/unions rather than primitive types.
 
 Under my idea, the derived type would be a union rather than a struct.
 This is because with the way D works, it doesn't make so much sense to
 add data members - since structs have value semantics, increasing the
 size means that it isn't really a value of the base type anymore.


In any case defining new type you loose implicit casting to base type. In
what situation size difference could cause a problem ?


 OTOH 
 it does make a bit of sense to add methods and/or views of the data to
 an existing struct (such as one defined in an external API).




 
 But I guess this idea could work on built-in types as well....
 
 Stewart.
 


-- 
          Vladimir
Apr 21 2005
prev sibling parent xs0 <xs0 xs0.com> writes:
 But this second bit isn't strictly necessary as it would be easy enough to
 define a template class for this purpose:
 








 
 So primitives could be inherited like so:
 
 class MyInt : ClassOf!(int) {}
 
 In fact I think I may define a class like this for Ares just to have it around.


Hmm, wouldn't a struct fit better, because of value semantics? It should 
be much faster, too, because there's no "this" and virtual function 
dereferencing going on..

OTOH, you can't derive structs, afaik, so it may not be a good thing to 
do in a template. You could probably mixin stuff, though; having a 
template with all the usual operators, and being able to add new stuff 
should be ok, I guess (for a silly example, it may be dangerous to have 
a type that behaves like an int with all the operators, except that if 
you divide it by 5 it formats your hard drive? What if you forget it 
does that? :)

xs0
Apr 10 2005