• Derek Parnell (35/35) Apr 01 2004 Ok, stupid question time.
• Ben Hinkle (11/44) Apr 01 2004 D doesn't have overloadable assignment
• Derek Parnell (12/64) Apr 01 2004 coming
• Ben Hinkle (17/58) Apr 02 2004 I don't really know all of Walter's reasons, but I think one of the
• Derek Parnell (20/37) Apr 02 2004 opAssign()
• Manfred Nowak (8/10) Apr 02 2004 [...]

"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

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

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


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

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.

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

"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


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.

 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

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!