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

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

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

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.

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.

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.

> 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