www.digitalmars.com         C & C++   DMDScript  

D - User defined conversions

reply "Derek Parnell" <Derek.Parnell psyc.ward> writes:
Ok, stupid question time.

How can I convert one of my classes into another. Specifically, I want to  
remove this message "cannot implicitly convert oeVector to oeValue" coming  
up. The only way I can work out how to do it so far is to define a method  
in oeValue that accepts an eoVector, eg...

   class oeValue
   {
      . . . snipped stuff . . .
      void value(oeVector X)
      {
         . . . do the conversion work . . .
      }
   }

then I can use this in my code ....

    oeValue a;
    oeVector b = new oeVector("abcdef");

    a.value(b);

but wouldn't it be nicer to this ...

    a = b;

or even ...

    a = cast(oeValue)b;

I'm thinking that maybe I can create an opCall() in oeValue like ...

    void opCall(oeVector X)
    {
      ... etc...
    }

then in my code I could say ...

    a(b);

I'm sure I'm missing the bleeding obvious, so any help would be  
appreciated.

-- 

cheers,
Derek Parnell


-- 
Derek
Apr 01 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
On Thu, 01 Apr 2004 18:13:09 +1000, "Derek Parnell"
<Derek.Parnell psyc.ward> wrote:

Ok, stupid question time.

How can I convert one of my classes into another. Specifically, I want to  
remove this message "cannot implicitly convert oeVector to oeValue" coming  
up. The only way I can work out how to do it so far is to define a method  
in oeValue that accepts an eoVector, eg...

   class oeValue
   {
      . . . snipped stuff . . .
      void value(oeVector X)
      {
         . . . do the conversion work . . .
      }
   }

then I can use this in my code ....

    oeValue a;
    oeVector b = new oeVector("abcdef");

    a.value(b);

but wouldn't it be nicer to this ...

    a = b;

D doesn't have overloadable assignment
or even ...

    a = cast(oeValue)b;

D doesn't have cast operators.
I'm thinking that maybe I can create an opCall() in oeValue like ...

    void opCall(oeVector X)
    {
      ... etc...
    }

then in my code I could say ...

    a(b);

would work and it is fairly common to make struct constructors using static opCall a = eoValue(b);
I'm sure I'm missing the bleeding obvious, so any help would be  
appreciated.

I'd model the toString API: eoValue toValue(oeVector X) {...} a = toValue(b); That name makes it clear it is making something new.
-- 

cheers,
Derek Parnell

Apr 01 2004
parent reply "Derek Parnell" <not available.com> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:037o60d4g5c70trs2hvoi68o1voqcq5j69 4ax.com...
 On Thu, 01 Apr 2004 18:13:09 +1000, "Derek Parnell"
 <Derek.Parnell psyc.ward> wrote:

Ok, stupid question time.

How can I convert one of my classes into another. Specifically, I want to
remove this message "cannot implicitly convert oeVector to oeValue"


up. The only way I can work out how to do it so far is to define a method
in oeValue that accepts an eoVector, eg...

   class oeValue
   {
      . . . snipped stuff . . .
      void value(oeVector X)
      {
         . . . do the conversion work . . .
      }
   }

then I can use this in my code ....

    oeValue a;
    oeVector b = new oeVector("abcdef");

    a.value(b);

but wouldn't it be nicer to this ...

    a = b;

D doesn't have overloadable assignment

Yeah, I can see that. What is the justification for not having an opAssign() method? On the surface it seems like a pretty limiting move, but I'm sure better heads have already decided it is a 'bad thing'. So I was just wondering why that would be considered so?
or even ...

    a = cast(oeValue)b;

D doesn't have cast operators.

Ditto. Another strange omission, IMHO. Any ideas why?
I'm thinking that maybe I can create an opCall() in oeValue like ...

    void opCall(oeVector X)
    {
      ... etc...
    }

then in my code I could say ...

    a(b);

would work and it is fairly common to make struct constructors using static opCall a = eoValue(b);
I'm sure I'm missing the bleeding obvious, so any help would be
appreciated.

I'd model the toString API: eoValue toValue(oeVector X) {...} a = toValue(b); That name makes it clear it is making something new.

Yeah, I can see that makes sense in the light of D's limitations. Pity we have to resort to 'work arounds' though. -- Derek
Apr 01 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
    a = b;

D doesn't have overloadable assignment

Yeah, I can see that. What is the justification for not having an opAssign() method? On the surface it seems like a pretty limiting move, but I'm sure better heads have already decided it is a 'bad thing'. So I was just wondering why that would be considered so?

I don't really know all of Walter's reasons, but I think one of the most common uses for overloading assignment was for memory management - ie who frees the pointer when it has been copied willy nilly? Given D has garbage collection that isn't a big deal. Plus class objects have reference semantics to copying an object is rare. Java and C# also don't have overloadable opAssign. Structs have value semantics so overloading opAssign could be useful there but structs are simple beasts now - though there was a thread recently asking for more class-like behaviors in structs.
or even ...

    a = cast(oeValue)b;

D doesn't have cast operators.

Ditto. Another strange omission, IMHO. Any ideas why?

nope - probably the same reasons as for assignment.
I'm thinking that maybe I can create an opCall() in oeValue like ...

    void opCall(oeVector X)
    {
      ... etc...
    }

then in my code I could say ...

    a(b);

would work and it is fairly common to make struct constructors using static opCall a = eoValue(b);
I'm sure I'm missing the bleeding obvious, so any help would be
appreciated.

I'd model the toString API: eoValue toValue(oeVector X) {...} a = toValue(b); That name makes it clear it is making something new.

Yeah, I can see that makes sense in the light of D's limitations. Pity we have to resort to 'work arounds' though.

I can understand someone coming from C++ can see these as limitations but I don't. I guess it depends on how often one uses them in C++. Think of it this way - in C++ every time you use assignment with some class you don't know well you have to go look to see what the heck the semantics are. In D assignment has well defined semantics so it makes my life as a user of the class much easier. -Ben
Apr 02 2004
parent reply "Derek Parnell" <not available.com> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:0tpq60pi04eclri30hbdetq8e633p4j65a 4ax.com...
    a = b;

D doesn't have overloadable assignment

Yeah, I can see that. What is the justification for not having an


method? On the surface it seems like a pretty limiting move, but I'm sure
better heads have already decided it is a 'bad thing'. So I was just
wondering why that would be considered so?

I don't really know all of Walter's reasons, but I think one of the most common uses for overloading assignment was for memory management - ie who frees the pointer when it has been copied willy nilly? Given D has garbage collection that isn't a big deal. Plus class objects have reference semantics to copying an object is rare. Java and C# also don't have overloadable opAssign. Structs have value semantics so overloading opAssign could be useful there but structs are simple beasts now - though there was a thread recently asking for more class-like behaviors in structs.

I'm not sure about GC yet, so I'll come back to that in a minute. Aside from RAM management there are other resources that might need to be released when a class object's internal variables are changed. Things such as open file handles, Windows font/bitmap/brush/pen/icon/... handles, database transactions, ... These are not dealt with during GC. As D stands now, we have to invent non-standard, and maybe even 'artifical', ways of emulating an opAssign method. For consistancy sake, an opAssign method makes sense to me. We have to create workarounds to pretend to have one nowadays to release non GC resources. The job of a programming language is to make life easier for coders, not language designers. Back to GC in D. Are you saying that a class never has to worry about releasing memory acquired, because of D's garbage collection methodology? If so, this is truely wonderful - and that's not sarcastic - I mean it literally. I must still do more research before commenting on this aspect. -- Derek
Apr 02 2004
parent Manfred Nowak <svv1999 hotmail.com> writes:
Derek Parnell wrote:

[...]
 The job of a programming language is to make life easier for coders, not
 language designers.

Partially agreed. There are other aspects, that a programming language must meet, here mentioning the maintenance phase only. In addition please note, that DigitalMars has very limited man power for D. Do you want to donate? So long!
Apr 02 2004