On Tue, 13 Jul 2004 07:27:15 +0000 (UTC), Arcane Jill <Arcane_member@pathlink.com> wrote:

> In article <opsa1oztn45a2sq9@digitalmars.com>, Regan Heath says...
>
>>>>> Could anybody explain me, in which I you'd want to overload opMul on
>>>>> classes?
>>>>
>>> Also the Int class (unlimited precision integer) in etc.bigint.bigint.
>>
>> Shouldn't these all be structs, not classes, they're 'value' types, not
>> 'reference' types aren't they?
>
> No.
>
> It is an absolute and unchangeable requirement that my Ints ***MUST*** have destructors, for reasons of security. Therefore they cannot be structs.
>
> They are immutable reference types.
> #        ^^^^^^^^^

The current implementation of them is sure. The concept however is a value type, just like a normal 'int'. The fact that you cannot write them as a value type, to me, suggests a deficiency in D.

So back to the main point, which IMO was 'does opMul make sense for a refence type?'

I think it makes sense for a value type, i.e. an int
I'm not sure it makes sense for a reference type.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

In article <cd05k8$25b0$1@digitaldaemon.com>, Derek Parnell says...

>   a(3.4);  // Initialize this one to 3.4
>   b(17);  // Initialize this one to 17
>   c("happy me");  // Initialize this one to "happy me"
>   d('?'); // Initialize this one to '?'
>
>Actually, I didn't like the look of this in code, so I overloaded "<<=" so I could also write ...
>
>  a <<= 3.4;
>  b <<= 17;
>  c <<= "happy me";
>  d <<= '?';
>
>Am I doing things the kosher 'D' way or am I way off base?

Tee hee. :-)

Well, there _IS_ no kosher D way, because opAssign() doesn't exist. Your solutions are kinda neat, and definitely fun.



>I know to the mathematical purists
>this is 'evil'. Presumably because they can only see "<<=" as shifting bits
>to the left and assigning the result to itself.

Ah now, to a REAL mathematical purist, << and >> are relations (they return a boolean result). a << b means "a is much less than b", while a >> b means "a is much greater than b". The use of << and >> to mean bitshifting did not come out of mathematics. C invented that one.

Jill

In article <cd08ld$2atb$1@digitaldaemon.com>, Derek Parnell says...

>So what's a better way? An explicit function call to assign a value?
>
>eg.
>
>   a.opAssign("hello")
>
>It sort of seems stupid to resort to doing this when the language already has an operator to do it...

The C++ standard template library uses a function called assign(). Of course, in C++, you can overload operator=(), but sometimes even this isn't enough, because sometimes you want more than one parameter on the right hand side of the equals (if you see what I mean). So in C++ you can end up with stuff like:

#    myString.assign(ptr, length);

This is pretty clear and unambiguous. For D, opAssign() would probably be a better name, even if it /isn't/ overloading =.

Jill

On Tue, 13 Jul 2004 11:21:40 +0000 (UTC), Arcane Jill wrote:

> In article <cd08ld$2atb$1@digitaldaemon.com>, Derek Parnell says...
> 
>>So what's a better way? An explicit function call to assign a value?
>>
>>eg.
>>
>>   a.opAssign("hello")
>>
>>It sort of seems stupid to resort to doing this when the language already has an operator to do it...
> 
> The C++ standard template library uses a function called assign(). Of course, in C++, you can overload operator=(), but sometimes even this isn't enough, because sometimes you want more than one parameter on the right hand side of the equals (if you see what I mean). So in C++ you can end up with stuff like:
> 
> #    myString.assign(ptr, length);
> 
> This is pretty clear and unambiguous. For D, opAssign() would probably be a better name, even if it /isn't/ overloading =.
> 

Yeah, I'm already using opSliceAssign(int x, int j, T x) in anticipation of
of overloading lvalue slices...
    a[i..j] = x;

where 'a' is NOT an array but a class or struct.

-- 
Derek
Melbourne, Australia

In article <opsa2m9oo15a2sq9@digitalmars.com>, Regan Heath says...
>
>I think you'll find if you read *my* reply to *my* post to which you are replying below you'll find that I rescinded my comment as I realised I had indeed missed the word 'static'.

Yeah I know. Whoops. <embarrassed>. Sometimes I'm just too impatient to read the whole list before posting anything.


>You make a good point about what goes on when someone uses a static opCall to emulate a constructor. I agree structs should have constructors. If they have constructors I think they should also have destructors.

Er... WHOA. They can't. That's just not possible in the D framework. And if you keep suggesting this all it means is that Walter will never give us CONstructors, which is a much more important priority.



>Thus allowing you to write your BigInt stuff with structs,

The class is called Int.

>which IMO they should be, as they're value types, not reference types.

They are immutable reference types, and I am perfectly happy with this. If you have an Int with a million digits, why on Earth would you want to copy that around by VALUE? (Ints can get indefinitely large. It's part of their definition).

I have no complaints about the struct/class distinction, and I'm happy for Int to be a class. Everything works fine, right now (minor bugs aside). I don't wish to change it to a struct, thank you very much.



>I also think structs should have inheritance. NOT in the same way as classes, NOT with any virtual function overhead, simply inherit methods and members. Sure, you can do this with mixins, but IMO they are messy, whereas struct inheritance could be quite clean.

You could always just name the first member variable "sooper". :-)

Have you considered that instead of wishing all this extra functionality on a struct, you could just use a class? You seem to be locked into this "value semantics therefore MUST be a struct" mentality, but that's not the only solution. D structs are simply lightweight aggregates. Treat them as such, and use classes if you want more.

It's really only the intialization of structs that (most) people are complaining
about.

Arcane Jill

In article <opsa2nh3aa5a2sq9@digitalmars.com>, Regan Heath says...

>The current implementation of them is sure. The concept however is a value type, just like a normal 'int'. The fact that you cannot write them as a value type, to me, suggests a deficiency in D.

It's a feature of D. I don't know if you could call it a deficiency. The "missing thing" (that C++ has and D doesn't) is a "thing" that has copy-by-value semantics, but also has a destructor. I'm sure Walter will be happy to explain how really HARD that is to do. You end up having to implement copy constructors, assignment operators and all sorts. D has it real easy right now - structs get bitwise-copied; classes get copied by reference. To end the "deficiency" you mentioned, D would have to get *MUCH* more compilicated. Even returning a value from a function could involve execution of a copy constructor, an assigment function, and a destructor (as it does in C++). In Walter's view that's way too much overcomplication, and so we should adjust our thinking to "the D way".

I adjusted my thinking, and now Ints work just fine, thank you very much.



>So back to the main point, which IMO was 'does opMul make sense for a refence type?'
>
>I think it makes sense for a value type, i.e. an int
>I'm not sure it makes sense for a reference type.

It makes sense in the D paradigm, which is that a struct is a lightweight aggregate, and a class is what you use if you want more powerful features than that.

But in partial agreement with you, I would certainly argue that
opMulAssign()
#    ^^^^^^
makes no sense where things are passed by reference. No probs with opMul()
itself though.

Arcane Jill

Regan Heath wrote:

> On Tue, 13 Jul 2004 07:27:15 +0000 (UTC), Arcane Jill
> <Arcane_member@pathlink.com> wrote:
> 
>> In article <opsa1oztn45a2sq9@digitalmars.com>, Regan Heath says...
>>
>>>>>> Could anybody explain me, in which I you'd want to overload opMul on classes?
>>>>>
>>>> Also the Int class (unlimited precision integer) in etc.bigint.bigint.
>>>
>>> Shouldn't these all be structs, not classes, they're 'value' types, not 'reference' types aren't they?
>>
>> No.
>>
>> It is an absolute and unchangeable requirement that my Ints ***MUST*** have destructors, for reasons of security. Therefore they cannot be structs.
>>
>> They are immutable reference types.
>> #        ^^^^^^^^^
> 
> The current implementation of them is sure. The concept however is a value type, just like a normal 'int'. The fact that you cannot write them as a value type, to me, suggests a deficiency in D.
> 
> So back to the main point, which IMO was 'does opMul make sense for a refence type?'
> 
> I think it makes sense for a value type, i.e. an int
> I'm not sure it makes sense for a reference type.
> 
> Regan.
> 

For another perspective on opMul and big-ints, see the wrapper I wrote for
GMP's mpz type at
  http://home.comcast.net/~benhinkle/gmp-d/doc/classmpz.html
It uses classes and overloads opMul to return a new value. In order to
prevent the GC from getting swamped with all those objects it uses a
recycling mechanism. Users can also get to the "low-level" C mpz datatype
to just call the GMP C functions if they want to manage the memory
allocations by hand. Performance of this wrapper is better (on complex
expressions) than the C++ wrapper that ships with GMP since the C++ version
has to constantly be creating and destroying temporaries. The code is
available at http://home.comcast.net/~benhinkle/gmp-d/

-Ben

Arcane Jill wrote:

>In article <cctj4p$115q$1@digitaldaemon.com>, Mike Parker says...
>
>  
>
>>struct Foo
>>{
>>   int x;
>>   static Foo opCall(int i)
>>   {
>>       Foo f;
>>       f.x = i;
>>       return f;
>>   }
>>}
>>
>>Foo foo = Foo(5);
>>    
>>
>
>See, Walter. I told you - people are using static opCall to simulate
>constructors. You can do this for both structs and classes. For structs, the
>advantage is, you GET constructor-like calls. For classes, the advantage is, you
>get to dispense with the unnecessary word "new".
>
>I have suggested this before (though I gather you didn't like the suggestion)
>that (1) structs should be allowed constructors; (2) the keyword "new" should be
>ditched, or at least made optional, in constructor calls; and (3) static opCall
>be deprecated in favor of constructors. The language would be SO much neater and
>cleaner with these changes built in.
>
>I find it hard to believe, after all, that the use of static opCall as
>demonstrated above was a DESIGN FEATURE of D. I mean - I've never seen static
>opCall used for any purpose OTHER than emulating constructors. I find it more
>believable that someone simply discovered that the compiler lets you get away
>with it, and started using it because structs don't have constructors. It would
>be really nice to tidy this up - even if only for syntactic consistency.
>
>Arcane Jill
>
>
>
>  
>
For what its worth, I completely agree.  One way or the other this feature should be generic.  One way to do things, please simplify the language in these regards.  I like how in many aspects of D how you think it should be done, is how it is done.   But in other areas this is worse then C++.  I still don't know all of C++, its just has to many odd rules of doing the same things.

-- 
-Anderson: http://badmama.com.au/~anderson/

> So what's a better way? An explicit function call to assign a value?
>
> eg.
>
>    a.opAssign("hello")
>
> It sort of seems stupid to resort to doing this when the language already has an operator to do it...

This might do as a temporary solution

    a.Is = "hello";

The intent is crystal clear and the expression is short.

Derek Parnell wrote:
> On Tue, 13 Jul 2004 18:21:23 +1000, Matthew Wilson wrote:
> 
> 
> [snip]
> 
> 
>>>But I see "<<=" as a way of
>>>saying 'copy the value on the right-side to the thing that's on the
>>>left-side'.  Gee, much like I see "=" really. Sure wish I could overload
>>>"=", 'cos that would make a lot of sense to me.
>>>
>>>I want to set the value of these structures but I don't want to deal with
>>>the internal repesentation all the time. That's why we have method's,
>>>right?
>>>
>>>
>>>Am I doing things the kosher 'D' way or am I way off base?
>>
>>It seems like one of these things that is convenient to its author (at the
>>time of writing - you'll be confused by it in six months' time) but is
>>likely to lead to a host of inconsistent behaviours amongst the
>>practitioners.
>>
>>So I'd say "way off base", I'm afraid
> 
> 
> Thanks mate. I sorta suspected so. Now if only I could overload '=' so my
> INTENTIONS to the code reader were a bit more obvious.
> 
> So what's a better way? An explicit function call to assign a value?
> 
> eg.
> 
>    a.opAssign("hello")
> 
> It sort of seems stupid to resort to doing this when the language already
> has an operator to do it...
> 
I'm all for overloading <<=
or else adding some sort of new operator like <-  for "deep copy"