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

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

"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"
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

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

>> >    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

"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
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.


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

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!