Walter's second axiom

Derek Parnell derek at nomail.afraid.org
Tue Dec 11 18:30:17 PST 2007


On Tue, 11 Dec 2007 18:57:17 -0500, Jason House wrote:

> Walter Bright wrote:
>> That axiom didn't really exist until Andrei started pointing out to me
>> all the advantages of being able to wrap types in a struct. So we can
>> expect some historical problems with it.
> 
> Can you please share with us all the advantages of "Any type T can be
> wrapped inside a struct S, and that S can be made to behave as a typedef
> for type T."
> 
> Under what conditions can it behave exactly like a typedef?  If it behaves
> *exactly* as a typedef under all circumstances, then it can't have any
> additional data members or member functions and must behave exactly like
> the original.  If that's true, why wrap it in a struct at all?

I don't think that Walter was suggesting that one actually does this ...

  struct LONG { long x; }
  LONG foo;

because that would be a bit pointless, and because it would also show that
you need to use different syntax when using structs rather than typedefs
...

struct longS { long x; }
typedef long longT ;

void main()
{

   longS foo;
   longT bar;
   
   foo.x = 1;   // One can't yet do "foo = cast(longS)1;"
   bar = cast(longT)2;
}

> I assume there has to be some way to bend that.  Candidates in my mind are
> extra data members and extra member functions.  Extra data members seems
> less likely because a cast from S to T and back to S would lose data
> (something that typedef's don't have happen).  Of course, this may fit into
> the grand scheme of opImplicitCast.
> 
> I also wonder if extending a class may be an alternative to wrapping it in a
> struct.  Maybe wrapping in a struct could be restricted to value types?  I
> just don't understand this enough yet to give any credible suggestions.

I needed a Currency data type. I chose to use a struct to wrap a long plus
some methods to get it. So my Currency is really a smart long but it
behaves 'like' a value type except for the special syntax required because
it *is* a struct. 

Of course I'd like to see a truly smart value type functionality added to
D, in which one could use the same syntax used for built-in value types.


   Currency actual_balance,
            available_balance,
            credit_limit,
            overlimit_amount
            ;
   Date     overlimit_date,
            current_processing_date
            ;
   int      overlimit_days;   
   . . . 

   if ( actual_balance <= credit_limit )
      overlimit_amount = 0;
   else
      overlimit_amount = credit_limit - actual_balance;

   if (available_balance <= credit_limit)
   {
      overlimit_date = null;
      overlimit_days = 0;
   }
   else
      overlimit_days = current_processing_date - overlimit_date;



-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
12/12/2007 12:59:14 PM



More information about the Digitalmars-d mailing list