www.digitalmars.com         C & C++   DMDScript  

D - [typedef] Property definitions

reply "C. Sauls" <ibisbasenji yahoo.com> writes:
Is it, or could it become, possible to do something like the following:

<snip>
typedef int dbref {
     // standard props
     init    : -1,
     min     : -3,
     max     : int function() {
         return db.maxObject;
     },

     // extension props
     valid   : bit function() {
         return this in db.objects && this >= 0;
     },
     object  : DBObj function() {
         if (this.valid)
             return db.objects[this];
         return null;
     }
}
</snip>

The extension properties idea might be a bit much, I admit.

-C. Sauls
-Invironz
Mar 08 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
On Mon, 08 Mar 2004 04:16:15 -0600, "C. Sauls" <ibisbasenji yahoo.com>
wrote:


Is it, or could it become, possible to do something like the following:

<snip>
typedef int dbref {
     // standard props
     init    : -1,
     min     : -3,
     max     : int function() {
         return db.maxObject;
     },


I don't think type properties can be functions - they are
needed at compile time.


     // extension props
     valid   : bit function() {
         return this in db.objects && this >= 0;
     },


"valid" should be a property of an object, not a type.


     object  : DBObj function() {
         if (this.valid)
             return db.objects[this];
         return null;
     }
}
</snip>


What's the differences between this approach and making dbref 
a struct with one int field in it? I think the struct will 
have the memory footprint of one int (since there is no inheritance
in a struct there is no need for a vtable). If I'm reading the
doc right structs can have properties and those are evaluated 
at run-time.

-Ben



The extension properties idea might be a bit much, I admit.

-C. Sauls
-Invironz
Mar 08 2004
parent reply "C. Sauls" <ibisbasenji yahoo.com> writes:
Comments imbedded.

Ben Hinkle wrote:

 I don't think type properties can be functions - they are
 needed at compile time.


I suppose it could default at compile time to the natural .max (to reuse 
my example) for the base type.


 

    // extension props
    valid   : bit function() {
        return this in db.objects && this >= 0;
    },


 
 
 "valid" should be a property of an object, not a type.


Except that in the program I use the 'dbref' type in, the dbref itself 
can be valid or invalid despite having a technically correct value.


 

    object  : DBObj function() {
        if (this.valid)
            return db.objects[this];
        return null;
    }
}
</snip>


 
 What's the differences between this approach and making dbref 
 a struct with one int field in it? I think the struct will 
 have the memory footprint of one int (since there is no inheritance
 in a struct there is no need for a vtable). If I'm reading the
 doc right structs can have properties and those are evaluated 
 at run-time.


If you're right, then there isn't much difference at all, except that I 
would have to reference the value of the dbref via a member -- not 
really a problem -- and I'd probably have to try making db.objects use 
the dbref struct as its key type.  I'll try doing it this way... 
although I still think being able to define the standard properties (at 
least) might have uses.  Too bad I don't know any other example.

-C. Sauls
-Invironz
Mar 08 2004
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
C. Sauls wrote:

[...]

 although I still think being able to define the standard properties (at
 least) might have uses.


[...]

Why that? I am in the other "camp": disallowing the redefinition of
standard properties and making them accessible only over the
`typeof(..).property' expression.

So long.
Mar 08 2004
parent reply "C. Sauls" <ibisbasenji yahoo.com> writes:
Let me re-use my example again.  A 'dbref' is derived from int, but in 
the logic of the program I'm working on there are only three negative 
values allowed:

-1 the 'nothing' object
-2 the 'ambiguous match' object
-3 the 'failed match' object

So naturally I'd like its .min to be -3, and its .init to be -1.  Sure I 
can just set up filter/check code, or just cross my fingers, but why 
should I have to, when being able to override .min would take care of 
that for me?  Maybe its laziness, but considering D's typedef creates 
strong types (if I read right) I think its a natural part of its 
purpose.  If I just wanted a normal int, I would've just used int, or 
alias'd it.

-C. Sauls
-Invironz

Manfred Nowak wrote:

 C. Sauls wrote:
 
 [...]
 

although I still think being able to define the standard properties (at
least) might have uses.


 
 [...]
 
 Why that? I am in the other "camp": disallowing the redefinition of
 standard properties and making them accessible only over the
 `typeof(..).property' expression.
 
 So long.
Mar 09 2004
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
C. Sauls wrote:

[...]

 when being able to override .min would take care of 
 that for me?


Now I understand that you want a variable subrange of the integer values.
Something like:

 int f(){
   ... do some calculations at runtime
       and return result
 }
 typedef [-3 .. f()] dbref; // whenever a variable of type dbref
                            // is accessed call f to check if
                            // its value is in range


 D's typedef creates strong types (if I read right)


But not in the sense, that the values, which the new type is able to
hold, differ from that values, which the type can hold from which the new
type is typedef'd.

In D one can even explicitely cast values into enums out of the range
which is denoted by the enums .min and .max properties.

And as far as I understand your design I think an enum containing the four
values {normal, nothing, ambiguous, failed} and an uint would be more
appropriate.
Mar 09 2004
parent "C. Sauls" <ibisbasenji yahoo.com> writes:
 And as far as I understand your design I think an enum containing the four
 values {normal, nothing, ambiguous, failed} and an uint would be more
 appropriate.


I think I understand that... just to see if I do or not, do you mean 
something like the following:

<snip>
struct DBRef {
   enum {
     Normal, Nothing, Ambiguous, Failed
   }

   uint  ref,
         cat = Nothing;
   ...
}

... in use elsewhere ...
char[] name;
DBRef dbref;
Var match;
...
if (dbref.cat == DBRef.Ambiguous) {
   if (match.type == LIST)
     throw new AmbiguousMatch(name, match.l);
   else // assume type == ERR
     throw new AmbiguousMatch(name, match.e);
}
...
</snip>

Hmm...  I think I'll stick with using plain int for right now.

-C. Sauls
-Invironz
Mar 09 2004