www.digitalmars.com         C & C++   DMDScript  

D - new properties for dynamic arrays

reply "Sandor Hojtsy" <hojtsy index.hu> writes:
I would like to come up again with an issue already discussed in some
details.
What stops us from (also) having

str4 = str1.left(5) ~ str2[3..4] ~ str3.right(6);

instead of

str4 = str1[0..4] ~ str2[3..4] ~ str3[str3.length-6..str3.length-1];

For me it seems much more intuitive, and easy enough to implement. Using the
"right" property can even be faster than slicing, due to the absence of
multiple indirections.

Yours,
Sandor
Jul 09 2002
next sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
That's not a bad idea!

We could also have some kind of .mid property that has a more natural syntax
than for array slicing.  Such as pos and count, and count would maybe be
rangechecked against the available size.

You could call the .left property .first or the .right property .last also,
to make it more generic and intuitive (not all strings read "left to right"
especially in Chinese etc)

Sean


"Sandor Hojtsy" <hojtsy index.hu> wrote in message
news:agec01$2alu$1 digitaldaemon.com...

 I would like to come up again with an issue already discussed in some
 details.
 What stops us from (also) having

 str4 = str1.left(5) ~ str2[3..4] ~ str3.right(6);

 instead of

 str4 = str1[0..4] ~ str2[3..4] ~ str3[str3.length-6..str3.length-1];

 For me it seems much more intuitive, and easy enough to implement. Using


the

 "right" property can even be faster than slicing, due to the absence of
 multiple indirections.

 Yours,
 Sandor
Jul 09 2002
prev sibling parent reply "anderson" <anderson firestar.com.au> writes:
Looks like a good idea.  I've always like how that could be done similarly
in VB. It should be part of the standard.

Of coarse you could always invent your own and write it like....

str4 = left(str1, 5) ~ str2[3..4] ~ right(str3, 6);

On a slightly different note.
Perhaps there could also be a way of creating your own attributes/properties
for arrays (or any type for that matter).  Perhaps that could be something
included in Generics when it's implemented. Or perhaps we should just stick
to using classes.

Hmmm....

Or perhaps the property (getters and setters) syntax in D could be
extended...

char[] left(char[] in String, int in value) {...}

Would be equate to...

    string2 = left(string, 5);
and ...
    string2 = string.left(5);

And the setter (if needed)

    void left(char[] in String, int in value) {...}

    string.left(5) = "The first 5 letters of this sentence.";

Or something along those lines...(I sense problems with what I just wrote).


"Sandor Hojtsy" <hojtsy index.hu> wrote in message
news:agec01$2alu$1 digitaldaemon.com...

 I would like to come up again with an issue already discussed in some
 details.
 What stops us from (also) having

 str4 = str1.left(5) ~ str2[3..4] ~ str3.right(6);

 instead of

 str4 = str1[0..4] ~ str2[3..4] ~ str3[str3.length-6..str3.length-1];

 For me it seems much more intuitive, and easy enough to implement. Using


the

 "right" property can even be faster than slicing, due to the absence of
 multiple indirections.

 Yours,
 Sandor
Jul 09 2002
parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:agga0i$1mop$1 digitaldaemon.com...

 Looks like a good idea.  I've always like how that could be done similarly
 in VB. It should be part of the standard.

 Of coarse you could always invent your own and write it like....

 str4 = left(str1, 5) ~ str2[3..4] ~ right(str3, 6);


You can not. Not without templates, or macros.
I would not define a separate "left" function for each array type I could
possibly use. No way.


 On a slightly different note.
 Perhaps there could also be a way of creating your own


attributes/properties

 for arrays (or any type for that matter).  Perhaps that could be something
 included in Generics when it's implemented. Or perhaps we should just


stick

 to using classes.


The problem is, that you are unable to mimic the behaviour of built-in types
(due to lack of operator overload), so you can not make a separate class
which seems to be the extension of the built-in array. (see the vector
template in c++ STL).
I can think of several other operations on arrays, which could happily fit
with the member function syntax. Such as insertion.
Yes I know you can "emulate" insertion with slicing. The code is ugly, and
dangerously redundant. I have a bet that the underlying code is slower that
the one which could be implemented for insertion.
Now if I, or a general library provider, want to make an array which has
insertion as a member function, I need to say goodbye to the [] operator.
Too bad.


 Hmmm....

 Or perhaps the property (getters and setters) syntax in D could be
 extended...

 char[] left(char[] in String, int in value) {...}


You mean something like:
anyType[] left(anyType[] in Array, int in value) { ... }


 Would be equate to...

     string2 = left(string, 5);
 and ...
     string2 = string.left(5);


That's interesting. It rather seems to me an extension of the function call
sytax. A rather promissing extension.
That means you can extend any class with member functions of a special kind:
- They can only access public members
- They are public
- They cannot be called based on context. (you allways need to specify the
object instance)

Appart from the last restriction it is like deriving a class from the base
class and giving it the same name. Several problems could be solved
elegantly with this extension.

Another idea based on this one: I would be happy to see a special access
keyword "shallow" for member functions. Such member function could only
access public members of the same class. It has to be public of course. It
is usefull for similar reasons than the private and protected members. To
help modularity. I could provide examples if you need.


 And the setter (if needed)

     void left(char[] in String, int in value) {...}


No. It differs only in return value type.


     string.left(5) = "The first 5 letters of this sentence.";

 Or something along those lines...(I sense problems with what I just


wrote).

That expression can be evaluated as replacing the first 5 array elements
with any number of other array elements; moving the rest of the array if
needed. But I don't think that this is really necessary. I would be happy
with only read-only properties for this time.

Yours,
Sandor
Jul 12 2002
parent reply "anderson" <anderson firestar.com.au> writes:
"Sandor Hojtsy" <hojtsy index.hu> wrote in message
news:agm9pc$1ati$1 digitaldaemon.com...

 "anderson" <anderson firestar.com.au> wrote in message
 news:agga0i$1mop$1 digitaldaemon.com...

 Looks like a good idea.  I've always like how that could be done




similarly

 in VB. It should be part of the standard.

 Of coarse you could always invent your own and write it like....

 str4 = left(str1, 5) ~ str2[3..4] ~ right(str3, 6);


 You can not. Not without templates, or macros.
 I would not define a separate "left" function for each array type I could
 possibly use. No way.


What about void (void * for arrays)? Or is that depreciated for variable use
in D? Anyway I'm assumping D will have generics in the future (2.0).


 On a slightly different note.
 Perhaps there could also be a way of creating your own


 attributes/properties

 for arrays (or any type for that matter).  Perhaps that could be




something

 included in Generics when it's implemented. Or perhaps we should just


 stick

 to using classes.


 The problem is, that you are unable to mimic the behaviour of built-in


types

 (due to lack of operator overload), so you can not make a separate class
 which seems to be the extension of the built-in array. (see the vector
 template in c++ STL).


Parhaps there could be a way to extend types into classes (and template
classes) and then use them.


 I can think of several other operations on arrays, which could happily fit
 with the member function syntax. Such as insertion.
 Yes I know you can "emulate" insertion with slicing. The code is ugly, and
 dangerously redundant. I have a bet that the underlying code is slower


that

 the one which could be implemented for insertion.
 Now if I, or a general library provider, want to make an array which has
 insertion as a member function, I need to say goodbye to the [] operator.
 Too bad.

 Hmmm....

 Or perhaps the property (getters and setters) syntax in D could be
 extended...

 char[] left(char[] in String, int in value) {...}


 You mean something like:
 anyType[] left(anyType[] in Array, int in value) { ... }


anyType[] left(void[] in Array, int in value) { ... }

Yeah, but In some cases you'd want to be specific.


 Would be equate to...

     string2 = left(string, 5);
 and ...
     string2 = string.left(5);


 That's interesting. It rather seems to me an extension of the function


call

 sytax. A rather promissing extension.
 That means you can extend any class with member functions of a special


kind:

 - They can only access public members
 - They are public
 - They cannot be called based on context. (you allways need to specify the
 object instance)

 Appart from the last restriction it is like deriving a class from the base
 class and giving it the same name. Several problems could be solved
 elegantly with this extension.

 Another idea based on this one: I would be happy to see a special access
 keyword "shallow" for member functions. Such member function could only
 access public members of the same class. It has to be public of course. It
 is usefull for similar reasons than the private and protected members. To
 help modularity. I could provide examples if you need.


No, I get the idea. It seems like a good idea, because many times you have
to much class information to deal with. The only disadvantage is that if
used improperly, code reuse could be sacificed. It should also apply to
member variables, just to make things complete.


 And the setter (if needed)

     void left(char[] in String, int in value) {...}


 No. It differs only in return value type.


Which is something I think D should have if you refur to my previous
disscussions about using cast() with the return type.

Actually, that code wouldn't have worked (no pointer to what we are
modifying). I relize that (that's way I said I sense problems). Parhaps...

void left(int in value, char[] in String, char[] inout String) {...}

Would be more apropriate. But still there are problems because how will the
compiler reconise it from a differn't type getter/setter type?


     string.left(5) = "The first 5 letters of this sentence.";

 Or something along those lines...(I sense problems with what I just


 wrote).

 That expression can be evaluated as replacing the first 5 array elements
 with any number of other array elements; moving the rest of the array if
 needed.


Exactly.


 But I don't think that this is really necessary. I would be happy
 with only read-only properties for this time.


I would also but I do like things to be complete, and read/write seems more
complete to me.


 Yours,
 Sandor
Jul 12 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
 What about void (void * for arrays)? Or is that depreciated for variable


use

 in D? Anyway I'm assumping D will have generics in the future (2.0).


I relize that void * brings in a list of other problems (such as size
determination).
Jul 13 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:agoc15$17v7$1 digitaldaemon.com...

 The problem is, that you are unable to mimic the behaviour of built-in




types

 (due to lack of operator overload), so you can not make a separate class
 which seems to be the extension of the built-in array. (see the vector
 template in c++ STL).


 Parhaps there could be a way to extend types into classes (and template
 classes) and then use them.


Maybe if you derive a struct from a basic type, you inherit all the
operators that apply to the basic type and can then override them?  Perhaps
in method syntax (named) form (such as "add" instead of "+")

I can think of a few uses for operator overloading where you just want the
operators for the basic type without the actual storage for it.  And
sometimes you want extra operators that the type doesn't ordinarily have.
Not to mention possibly operators that *no* builtin types possess.

Sean
Jul 13 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:agoqpa$23p4$1 digitaldaemon.com...

 "anderson" <anderson firestar.com.au> wrote in message
 news:agoc15$17v7$1 digitaldaemon.com...

 The problem is, that you are unable to mimic the behaviour of built-in




 types

 (due to lack of operator overload), so you can not make a separate






class

 which seems to be the extension of the built-in array. (see the vector
 template in c++ STL).


 Parhaps there could be a way to extend types into classes (and template
 classes) and then use them.


 Maybe if you derive a struct from a basic type, you inherit all the
 operators that apply to the basic type and can then override them?


Perhaps

 in method syntax (named) form (such as "add" instead of "+")

 I can think of a few uses for operator overloading where you just want the
 operators for the basic type without the actual storage for it.  And
 sometimes you want extra operators that the type doesn't ordinarily have.
 Not to mention possibly operators that *no* builtin types possess.

 Sean


 Sounds like a good idea. How would the syntax look? Keep the brain storming
comming.

--I remember java did it using clases (ie the integer class). I know that
it's methods were ineffecient and unclean, but that fact that they
implemented it must of ment that there was some use for it.
Jul 13 2002
prev sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:agoqpa$23p4$1 digitaldaemon.com...


<SNIP>

 Maybe if you derive a struct from a basic type, you inherit all the
 operators that apply to the basic type and can then override them?


Perhaps

 in method syntax (named) form (such as "add" instead of "+")

 I can think of a few uses for operator overloading where you just want the
 operators for the basic type without the actual storage for it.  And
 sometimes you want extra operators that the type doesn't ordinarily have.
 Not to mention possibly operators that *no* builtin types possess.

 Sean


The best thing to me still seems to be giving Object
a few extra methods, such as add(), sub(), mul()
and div() and map the operators to calls to these
functions. This is already done for == I believe?

The standard implementation of these methods in Object
would be to just throw an exception, while descendant
classes may choose to override this behaviour.
The problem is you would also need to have overloaded
versions of these methods for the basic types, but
that just means Object will have a lot of methods, not
a real serious problem. I think the basic types are
pretty fixed?

For the operator + you would have:

class Object
{
   // .....
   Object add (Object param);
   Object add (int param);
   Object add (extended param);
   Object add (char param);
   Object add (complex param);

   // Ofcourse the ideal form would be with templates
   <template T>
   Object add (T param);
}

So I think this is something for D 2.0
What problems do you see with an approach such as
this? Any insights?


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail



 Jul 14 2002



 next sibling parent reply "anderson" <anderson firestar.com.au>  writes:


 The best thing to me still seems to be giving Object
 a few extra methods, such as add(), sub(), mul()
 and div() and map the operators to calls to these
 functions. This is already done for == I believe?

 The standard implementation of these methods in Object
 would be to just throw an exception, while descendant
 classes may choose to override this behaviour.
 The problem is you would also need to have overloaded
 versions of these methods for the basic types, but
 that just means Object will have a lot of methods, not
 a real serious problem. I think the basic types are
 pretty fixed?

 For the operator + you would have:

 class Object
 {
    // .....
    Object add (Object param);
    Object add (int param);
    Object add (extended param);
    Object add (char param);
    Object add (complex param);

    // Ofcourse the ideal form would be with templates
    <template T>
    Object add (T param);
 }

 So I think this is something for D 2.0
 What problems do you see with an approach such as
 this? Any insights?


Yes, that's pretty simular to C++ but with nicer syntax. We were discussing
being able to add "D properties" to standard data types and arrays.

so,

class Object : int
{
...
}

or as Sean suggested use,

struct Object : int
{

}

Also you should add app (append ~) to your list.


 --
 Stijn
 OddesE_XYZ hotmail.com
 http://OddesE.cjb.net
 _________________________________________________
 Remove _XYZ from my address when replying by mail





 Jul 14 2002



  parent  "OddesE" <OddesE_XYZ hotmail.com>  writes:


"anderson" <anderson firestar.com.au> wrote in message
news:agtj1g$l6t$1 digitaldaemon.com...


<SNIP>

 Also you should add app (append ~) to your list.



Yes, you are right.


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail



 Jul 16 2002



prev sibling  parent reply "Walter" <walter digitalmars.com>  writes:


"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:ags8db$2eot$1 digitaldaemon.com...

 The best thing to me still seems to be giving Object
 a few extra methods, such as add(), sub(), mul()
 and div() and map the operators to calls to these
 functions. This is already done for == I believe?


This is a pretty good idea. My only objection is that I never liked the C++
approach of being able to override the global operator+ too, producing the
confusing combination of:

struct A
{
    int operator + (X);
};
int operator+ (A, X);

Note the inherent asymmetry of this, especially if A::operator+ turns out to
be virtual. The STL has some complicated examples of how to get into trouble
with this, especially when you throw templates into the mix.

A better approach would be to simply disallow overloading the global
operators, and say "no" to overloading the syntax:

    1 + A;

An alternative is for the compiler to rewrite (1+A) as (A+1) and then look
for an operator+ overload, but that can lead to trouble for (A+B) where both
A and B overload operator+.



 Jul 24 2002



 next sibling parent reply Pavel Minayev <evilone omen.ru>  writes:


On Wed, 24 Jul 2002 18:09:33 -0700 "Walter" <walter digitalmars.com> wrote:


 A better approach would be to simply disallow overloading the global
 operators, and say "no" to overloading the syntax:
 
     1 + A;


On other hand, it might be even better to disallow _member_ operators,
and require all operators overloading to be global. Then, you don't
have to care about things like virtual operators, overloading etc -
it's all naturally done by pointer conversions.
 



 Jul 24 2002



  parent reply "Walter" <walter digitalmars.com>  writes:


"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374624470316435 news.digitalmars.com...

 On Wed, 24 Jul 2002 18:09:33 -0700 "Walter" <walter digitalmars.com>


wrote:

 A better approach would be to simply disallow overloading the global
 operators, and say "no" to overloading the syntax:

     1 + A;


 On other hand, it might be even better to disallow _member_ operators,
 and require all operators overloading to be global. Then, you don't
 have to care about things like virtual operators, overloading etc -
 it's all naturally done by pointer conversions.


Of course, you're right, but unfortunately I screwed up and allowed the cmp
operator to be a member <g>.



 Aug 01 2002



  parent  Pavel Minayev <evilone omen.ru>  writes:


On Thu, 1 Aug 2002 15:30:13 -0700 "Walter" <walter digitalmars.com> wrote:


 Of course, you're right, but unfortunately I screwed up and allowed the cmp
 operator to be a member <g>.


Then, with introduction of new overloading scheme, the default version
of operator(==) and friends would just call cmp(). =) 



 Aug 02 2002



prev sibling next sibling parent reply Patrick Down <pat codemoon.com>  writes:


"Walter" <walter digitalmars.com> wrote in
news:ahnj39$133m$1 digitaldaemon.com:  

 A better approach would be to simply disallow overloading the global
 operators, and say "no" to overloading the syntax:
 
     1 + A;
 
 An alternative is for the compiler to rewrite (1+A) as (A+1) and then
 look for an operator+ overload, but that can lead to trouble for (A+B)
 where both A and B overload operator+.


There are mathmatical systems where A*B != B*A.

I'm sort of inclined to agree with Pavel and
say that all operators must be defined globally.
The only problem would be not being able to acess 
private members.



 Jul 25 2002



 next sibling parent reply "anderson" <anderson firestar.com.au>  writes:


"Patrick Down" <pat codemoon.com> wrote in message
news:Xns92565926D1F8Cpatcodemooncom 63.105.9.61...

 "Walter" <walter digitalmars.com> wrote in
 news:ahnj39$133m$1 digitaldaemon.com:

 A better approach would be to simply disallow overloading the global
 operators, and say "no" to overloading the syntax:

     1 + A;

 An alternative is for the compiler to rewrite (1+A) as (A+1) and then
 look for an operator+ overload, but that can lead to trouble for (A+B)
 where both A and B overload operator+.


 There are mathmatical systems where A*B != B*A.

 I'm sort of inclined to agree with Pavel and
 say that all operators must be defined globally.
 The only problem would be not being able to acess
 private members.


And protected... You'd end up writting your own add/sub/ect... method
anyway.

Order is signficatant. Parhaps you could provide 3 versions with special
rules?

Both (default) - Only usable if the other class doesn't have a Both property
to do with this class. (ie this class can't Both to itself.)
Left (L) - Only usable if the other class doesn't have a Right property to
do with this class. (ie this class can Left to itself)
Right (R) - Only usable if the other class doesn't have a Left property to
do with this class.

There doesn't seem to be an easy solution to this problem. There are
probably problems that can still occur with the above.



 Jul 25 2002



 next sibling parent reply Pavel Minayev <evilone omen.ru>  writes:


On Fri, 26 Jul 2002 00:10:16 +0800 "anderson" <anderson firestar.com.au> wrote:


 I'm sort of inclined to agree with Pavel and
 say that all operators must be defined globally.
 The only problem would be not being able to acess
 private members.


 
 And protected... You'd end up writting your own add/sub/ect... method
 anyway.


Operator overloading is typically used from _within_ the module
where classes are defined, so maybe a special rule stating that
overloaded operator can access private/protected class members
in classes it gets as arguments? Yes, it will be a violation of
strict OOP-approach, but at least it'd: 1) work, and 2) be easy
to understand.
 



 Jul 25 2002



  parent  Patrick Down <pat codemoon.com>  writes:


Pavel Minayev <evilone omen.ru> wrote in
news:CFN374629860625579 news.digitalmars.com: 


 On Fri, 26 Jul 2002 00:10:16 +0800 "anderson"
 <anderson firestar.com.au> wrote: 
 

 I'm sort of inclined to agree with Pavel and
 say that all operators must be defined globally.
 The only problem would be not being able to acess
 private members.


 
 And protected... You'd end up writting your own add/sub/ect... method
 anyway.


 
 Operator overloading is typically used from _within_ the module
 where classes are defined, so maybe a special rule stating that
 overloaded operator can access private/protected class members
 in classes it gets as arguments? Yes, it will be a violation of
 strict OOP-approach, but at least it'd: 1) work, and 2) be easy
 to understand.
  


How about static class members?

class Foo
{

  static add(Foo a, Foo b) { }
  static add(Foo a, int b) { }
};



 Jul 25 2002



prev sibling  parent reply Suporte Internet <suporte spica.mps.com.br>  writes:


Why not suply diferent methods for handling comutativity and
associativity :

class x : y
{
	override void comute(...) { ... }
	override void associate(...) {...}
	void add(...) { ... }
	void mul(...) {...}
	void div(...) {...}
	void dif(...) {...}
}

anderson <anderson firestar.com.au> wrote:

 
 "Patrick Down" <pat codemoon.com> wrote in message
 news:Xns92565926D1F8Cpatcodemooncom 63.105.9.61...

 "Walter" <walter digitalmars.com> wrote in
 news:ahnj39$133m$1 digitaldaemon.com:

 A better approach would be to simply disallow overloading the global
 operators, and say "no" to overloading the syntax:

     1 + A;

 An alternative is for the compiler to rewrite (1+A) as (A+1) and then
 look for an operator+ overload, but that can lead to trouble for (A+B)
 where both A and B overload operator+.


 There are mathmatical systems where A*B != B*A.

 I'm sort of inclined to agree with Pavel and
 say that all operators must be defined globally.
 The only problem would be not being able to acess
 private members.


 
 And protected... You'd end up writting your own add/sub/ect... method
 anyway.
 
 Order is signficatant. Parhaps you could provide 3 versions with special
 rules?
 
 Both (default) - Only usable if the other class doesn't have a Both property
 to do with this class. (ie this class can't Both to itself.)
 Left (L) - Only usable if the other class doesn't have a Right property to
 do with this class. (ie this class can Left to itself)
 Right (R) - Only usable if the other class doesn't have a Left property to
 do with this class.
 





 Jul 25 2002



  parent  Mark Evans <Mark_member pathlink.com>  writes:


Forgive me for joining a conversation I have not followed but I saw some
comments about operators.

Has anyone looked into blitz++?  This is a cool C++ library with special
expressiveness.

Given the chance to define a whole new language better than C++ I should think D
could do at least as well.  Take a peek at it!

Sorry if this comment is not exactly on-topic.

M.



 Jul 25 2002



prev sibling  parent reply "OddesE" <OddesE_XYZ hotmail.com>  writes:


"Patrick Down" <pat codemoon.com> wrote in message
news:Xns92565926D1F8Cpatcodemooncom 63.105.9.61...
<SNIP>

 There are mathmatical systems where A*B != B*A.


Does this hold for builtin types?
What I mean is that I know that for matrix mul
this is true, so MatA * MatB != MatB * MatA,
but I think that that is not a problem, because
this rule only applies to builtin types such as
int and double? MatA * 2.0 == 2.0 * MatA
isn't it?

Do you have an example where this would be
a problem? e.g. object * int != int * object
or object * double != double * object?

Maybe with complex numbers?
Mmmm....

--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail



 Jul 25 2002



  parent  Mark Evans <Mark_member pathlink.com>  writes:


For whatever my vote is worth -- as a long time user of mathematics systems like
Mathematica -- I would like commutivity to be user-definable.

Even though Mathematica is a fantastic symbolic solver, it is awful for
noncommutative work, precisely because of built in assumptions about
commutivity.  I would rather the compiler let me tell it what I want for any
given operator.

M.



 Jul 25 2002



prev sibling next sibling parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com>  writes:


"Walter" <walter digitalmars.com> wrote in message
news:ahnj39$133m$1 digitaldaemon.com...


 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:ags8db$2eot$1 digitaldaemon.com...

 The best thing to me still seems to be giving Object
 a few extra methods, such as add(), sub(), mul()
 and div() and map the operators to calls to these
 functions. This is already done for == I believe?


 This is a pretty good idea. My only objection is that I never liked the


C++

 approach of being able to override the global operator+ too, producing the
 confusing combination of:

 struct A
 {
     int operator + (X);
 };
 int operator+ (A, X);

 Note the inherent asymmetry of this, especially if A::operator+ turns out


to

 be virtual. The STL has some complicated examples of how to get into


trouble

 with this, especially when you throw templates into the mix.

 A better approach would be to simply disallow overloading the global
 operators, and say "no" to overloading the syntax:

     1 + A;

 An alternative is for the compiler to rewrite (1+A) as (A+1) and then look
 for an operator+ overload, but that can lead to trouble for (A+B) where


both

 A and B overload operator+.


   Like anderson said. You can use different versions. I'd use two, the
"normal" version and the reverse version:

class Vector: object {
  Vector add(Vector other); // Enough for both commutations
  Vector mul(double other); // Vector * double
  Vector rmul(double other); // double * Vector
};

class Matrix: object {
  Matrix add(Matrix other); // Enough for both commutations
  Matrix mul(double other); // Matrix * double
  Matrix rmul(double other); // double * Matrix
  Vector rmul(Vector other); // Vector * Matrix
};

   You can always easily do the disambiguation in whichever manner is most
consistent with D rules.

Salutaciones,
                         JCAB



 Jul 25 2002



  parent  "Walter" <walter digitalmars.com>  writes:


That is a good idea. I'm sorry I missed it when anderson said it.

"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message
news:ahpjb0$7k7$1 digitaldaemon.com...

  Like anderson said. You can use different versions. I'd use two, the
 "normal" version and the reverse version:

 class Vector: object {
   Vector add(Vector other); // Enough for both commutations
   Vector mul(double other); // Vector * double
   Vector rmul(double other); // double * Vector
 };

 class Matrix: object {
   Matrix add(Matrix other); // Enough for both commutations
   Matrix mul(double other); // Matrix * double
   Matrix rmul(double other); // double * Matrix
   Vector rmul(Vector other); // Vector * Matrix
 };

    You can always easily do the disambiguation in whichever manner is most
 consistent with D rules.

 Salutaciones,
                          JCAB





 Aug 01 2002



prev sibling  parent reply "Sandor Hojtsy" <hojtsy index.hu>  writes:


"Walter" <walter digitalmars.com> wrote in message
news:ahnj39$133m$1 digitaldaemon.com...

 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:ags8db$2eot$1 digitaldaemon.com...

 The best thing to me still seems to be giving Object
 a few extra methods, such as add(), sub(), mul()
 and div() and map the operators to calls to these
 functions. This is already done for == I believe?


 This is a pretty good idea.


Gee, Walter, so you are not completely against operator overloading, after
all.
But what would be the parameters of those methods in Object? I hope not:
void add(Object a, Object b)
Because "2" is not an Object. So you already need some kind of template
here.


 My only objection is that I never liked the C++
 approach of being able to override the global operator+ too, producing the
 confusing combination of:

 struct A
 {
     int operator + (X);
 };
 int operator+ (A, X);

 Note the inherent asymmetry of this, especially if A::operator+ turns out


to

 be virtual. The STL has some complicated examples of how to get into


trouble

 with this, especially when you throw templates into the mix.

 A better approach would be to simply disallow overloading the global
 operators, and say "no" to overloading the syntax:

     1 + A;


Saying "no" seems too restrictive. And counter-intuitive, isn't it? But as
told on other threads, with some syntax sugar, you don't need global
operator for this.


 An alternative is for the compiler to rewrite (1+A) as (A+1) and then look
 for an operator+ overload, but that can lead to trouble for (A+B) where


both

 A and B overload operator+.


How would you rewrite 1-A ?

Sandor



 Jul 30 2002



  parent reply Pavel Minayev <evilone omen.ru>  writes:


On Tue=2C 30 Jul 2002 11=3A00=3A57 +0200 =22Sandor Hojtsy=22
=3Chojtsy=40index=2Ehu=3E wrote=3A

=3E Gee=2C Walter=2C so you are not completely against operator overloading=2C
after
=3E all=2E
=3E But what would be the parameters of those methods in Object=3F I hope not=3A
=3E void add=28Object a=2C Object b=29
=3E Because =222=22 is not an Object=2E So you already need some kind of
template
=3E here=2E

I guess it'd work like this=3A

=09class Vector
=09{
=09=09=2E=2E=2E
=09=09Vector mul=28Vector v=29 { =2E=2E=2E }=09=09=2F=2F Vector + Vector
=09=09Vector mul=28int n=29 { =2E=2E=2E }=09=09=2F=2F Vector + int
=09}

But then=2C what about int + Vector=3F
I still think static methods with special syntax would be better=3A

=09class Vector
=09{
=09=09=2E=2E=2E
=09=09static operator* =28Vector a=2C Vector b=29 { =2E=2E=2E }
=09=09static operator* =28Vector a=2C int b=29 { =2E=2E=2E }
=09}

Short and clear=2E
 
=3E How would you rewrite 1-A =3F

-=28A-1=29=2C assuming that we can overload unary operators as well=2E
But it might not always work=2E



 Jul 30 2002



 next sibling parent reply "Sandor Hojtsy" <hojtsy index.hu>  writes:


"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374676619595486 news.digitalmars.com...


 How would you rewrite 1-A ?





-(A-1), assuming that we can overload unary operators as well.
But it might not always work.


Only if unary minus is actually overloaded. Or would you require to overload
it for all cases where the binary minus is overloaded? And also restrict
binary minus operations to those which satisfy -(A-1) == 1-A ??
For example: You are creating a class to implement a "set" of integers.
Set a = new Set, b = new Set;
a ~= 1; a ~= 3; a ~= 6;
b ~= 3; b ~= 4;
Set c = a - b;
As defined by the well known set operations, "c" will contain the elements
which are present in "a", but not in "b".
Now -(a-b) != b-a. Yes, I know you don't need to reorder here, but the
example shows that you should not altogether disallow binary minus
where -(a-b) != b-a. So you cannot reorder in all cases. How should the
compiler now when is it OK to reorder? It brings in more problems, than the
few it solves.
Conclusion: This reorder idea is Baaad.

Yours,
Sandor



 Jul 30 2002



  parent reply Pavel Minayev <evilone omen.ru>  writes:


On Tue, 30 Jul 2002 16:52:25 +0200 "Sandor Hojtsy" <hojtsy index.hu> wrote:


 Conclusion: This reorder idea is Baaad.


Agreed. I just wanted to show how it _could_ be done. But I
definitely don't like it.



 Jul 30 2002



  parent  "Walter" <walter digitalmars.com>  writes:


"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374678967827778 news.digitalmars.com...

 On Tue, 30 Jul 2002 16:52:25 +0200 "Sandor Hojtsy" <hojtsy index.hu>


wrote:

 Conclusion: This reorder idea is Baaad.


 Agreed. I just wanted to show how it _could_ be done. But I
 definitely don't like it.


Yes, reordering will not work. Reordering relies on special properties of
integers, which don't even apply to floating point operations.



 Aug 03 2002



prev sibling next sibling parent  "Juan Carlos Arevalo Baeza" <jcab roningames.com>  writes:


"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374676619595486 news.digitalmars.com...


I guess it'd work like this:

class Vector
{
...
Vector mul(Vector v) { ... } // Vector + Vector
Vector mul(int n) { ... } // Vector + int
}

But then, what about int + Vector?


   As I said, a simple and complete solution would be:

class Vector
{
...
Vector mul(Vector v) { ... } // Vector + Vector
Vector mul(int n) { ... } // Vector + int
Vector reverse_mul(int n) { ... } // int + Vector
}

   Ahem... being verbose ;-)

Salutaciones,
                         JCAB



 Jul 30 2002



prev sibling next sibling parent  "OddesE" <OddesE_XYZ hotmail.com>  writes:


"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374676619595486 news.digitalmars.com...
On Tue, 30 Jul 2002 11:00:57 +0200 "Sandor Hojtsy" <hojtsy index.hu> wrote:

 I still think static methods with special syntax would be better:

 class Vector
 {
 ...
 static operator* (Vector a, Vector b) { ... }
 static operator* (Vector a, int b) { ... }
 }

 Short and clear.


Sounds good, you have my vote on this!
I don't know about operator* as a name though..., this would
forbid calling the function directly wouldn't it? I can imagine
some operator-overloading haters not being happy with
that...If you would call it mul you could also call it directly,
some people might prefer that...


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail



 Jul 31 2002



prev sibling next sibling parent reply "anderson" <anderson firestar.com.au>  writes:


"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374676619595486 news.digitalmars.com...
On Tue, 30 Jul 2002 11:00:57 +0200 "Sandor Hojtsy" <hojtsy index.hu> wrote:


 class Vector
 {
 ...
 static operator* (Vector a, Vector b) { ... }
 static operator* (Vector a, int b) { ... }
 }



 Short and clear.


I think * would be confused with pointers.


 How would you rewrite 1-A ?




Juan offered a better solution I think because you get proper access to the
object properties and it's less special-case.



 Jul 31 2002



  parent reply Jonathan Andrew <jon ece.arizona.edu>  writes:


anderson wrote:

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN374676619595486 news.digitalmars.com...
 On Tue, 30 Jul 2002 11:00:57 +0200 "Sandor Hojtsy" <hojtsy index.hu> wrote:
 
 

class Vector
{
...
static operator* (Vector a, Vector b) { ... }
static operator* (Vector a, int b) { ... }
}


 
 

Short and clear.


 
 
 I think * would be confused with pointers.
 
 

How would you rewrite 1-A ?




 
 Juan offered a better solution I think because you get proper access to the
 object properties and it's less special-case.
 
 


You would have to have different 'keywords' for each symbol, i.e,
for vectors you might want to overload * for cross product and
constant multiples, but have . for dot product also, which one
would mul be? I suppose you could have a dot keyword also, but I
like the idea of being able to explicitly specify which symbol to
use.

Maybe something like
class Vector
{
      static operator(*) cross(VectorA, VectorB);
      static operator(*) mul(VectorA, int);
      static operator(.) dot(VectorA, VectorB);
      .... etc.
}

This way, those who don't like operator overloading could
still call the functions by name, i.e. cross(), dot() etc.
and you could specify which symbol to use also.
Just an idea,
  -Jon



 Jul 31 2002



 next sibling parent reply "anderson" <anderson firestar.com.au>  writes:


"Jonathan Andrew" <jon ece.arizona.edu> wrote in message
news:3D4862F1.3070709 ece.arizona.edu...

 anderson wrote:

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN374676619595486 news.digitalmars.com...
 On Tue, 30 Jul 2002 11:00:57 +0200 "Sandor Hojtsy" <hojtsy index.hu>




wrote:

class Vector
{
...
static operator* (Vector a, Vector b) { ... }
static operator* (Vector a, int b) { ... }
}




Short and clear.



 I think * would be confused with pointers.



How would you rewrite 1-A ?




 Juan offered a better solution I think because you get proper access to




the

 object properties and it's less special-case.


 You would have to have different 'keywords' for each symbol, i.e,
 for vectors you might want to overload * for cross product and
 constant multiples, but have . for dot product also, which one
 would mul be? I suppose you could have a dot keyword also, but I
 like the idea of being able to explicitly specify which symbol to
 use.

 Maybe something like
 class Vector
 {
       static operator(*) cross(VectorA, VectorB);
       static operator(*) mul(VectorA, int);
       static operator(.) dot(VectorA, VectorB);
       .... etc.
 }

 This way, those who don't like operator overloading could
 still call the functions by name, i.e. cross(), dot() etc.
 and you could specify which symbol to use also.
 Just an idea,
   -Jon


No, I agree with you. I was thinking (to stop it looking pointerish) ...

 class Vector
 {
       operator<*>(VectorA, VectorB);
       operator<->(VectorA, int);
       operator<.>(VectorA, VectorB);
       .... etc.
 }
Or another symbol because () makes it look like a weird function (but is
better then without).

because it's having to remember the name for each symbol simply means more
learning. The more things you have in the language the more you need to
remember. However if the user could specify any name they wished... Anyhow
in your example how would the complier determine the differce between a
cross and a mul? I think that would be a bug.

Also I think that it shouldn't be static. I like Juan's approach here
better.

My approch is closest to Juan (uses differn't syntax).

 class VectorA
 {
       leftOperator<*>(VectorB);
       leftOperator<->(int);
       leftOperator<.>(VectorB);
       rightOperator<.>(VectorB);
 }

or even simpler

 class VectorA
 {
       left<*>(VectorB);
       left<->(int);
       left<.>(VectorB);
       right<.>(VectorB);
 }

and users who what to specify...

 class VectorA
 {
       left<*> mul(VectorB);
       left<-> whatever(int);
       left<.> dot(VectorB);
       right<.> dot(VectorB);
 }

This way you don't have to special case access to class member properties.
If you give programs to much power, some are likly to abuse it.



 Jul 31 2002



 next sibling parent reply Jonathan Andrew <jon ece.arizona.edu>  writes:


 
 No, I agree with you. I was thinking (to stop it looking pointerish) ...
 
  class Vector
  {
        operator<*>(VectorA, VectorB);
        operator<->(VectorA, int);
        operator<.>(VectorA, VectorB);
        .... etc.
  }
 Or another symbol because () makes it look like a weird function (but is
 better then without).


True, <> would be a good choice.


 because it's having to remember the name for each symbol simply means more
 learning. The more things you have in the language the more you need to
 remember. However if the user could specify any name they wished... Anyhow
 in your example how would the complier determine the differce between a
 cross and a mul? I think that would be a bug.


It would determine it from the operators, if you had cross and mul
that both accepted two vectors, it should err.
In my case mul was a constant multiplier.


 Also I think that it shouldn't be static. I like Juan's approach here
 better.


Having static operators available (though not necessary) would be
convenient for a lot of cases, like a math class.


 My approch is closest to Juan (uses differn't syntax).
 
  class VectorA
  {
        leftOperator<*>(VectorB);
        leftOperator<->(int);
        leftOperator<.>(VectorB);
        rightOperator<.>(VectorB);
  }
 
 or even simpler
 
  class VectorA
  {
        left<*>(VectorB);
        left<->(int);
        left<.>(VectorB);
        right<.>(VectorB);
  }
 
 and users who what to specify...
 
  class VectorA
  {
        left<*> mul(VectorB);
        left<-> whatever(int);
        left<.> dot(VectorB);
        right<.> dot(VectorB);
  }
 
 This way you don't have to special case access to class member properties.
 If you give programs to much power, some are likly to abuse it.
 
 


Hmm, I dunno, that is more concise, but it seems a little harder to
understand.



 Jul 31 2002



 next sibling parent  "anderson" <anderson firestar.com.au>  writes:


"Jonathan Andrew" <jon ece.arizona.edu> wrote in message
news:3D48D3BE.404 ece.arizona.edu...

 No, I agree with you. I was thinking (to stop it looking pointerish) ...

  class Vector
  {
        operator<*>(VectorA, VectorB);
        operator<->(VectorA, int);
        operator<.>(VectorA, VectorB);
        .... etc.
  }
 Or another symbol because () makes it look like a weird function (but is
 better then without).


 True, <> would be a good choice.


 because it's having to remember the name for each symbol simply means




more

 learning. The more things you have in the language the more you need to
 remember. However if the user could specify any name they wished...




Anyhow

 in your example how would the complier determine the differce between a
 cross and a mul? I think that would be a bug.


 It would determine it from the operators, if you had cross and mul
 that both accepted two vectors, it should err.
 In my case mul was a constant multiplier.


 Also I think that it shouldn't be static. I like Juan's approach here
 better.


 Having static operators available (though not necessary) would be
 convenient for a lot of cases, like a math class.


 My approch is closest to Juan (uses differn't syntax).

  class VectorA
  {
        leftOperator<*>(VectorB);
        leftOperator<->(int);
        leftOperator<.>(VectorB);
        rightOperator<.>(VectorB);
  }

 or even simpler

  class VectorA
  {
        left<*>(VectorB);
        left<->(int);
        left<.>(VectorB);
        right<.>(VectorB);
  }

 and users who what to specify...

  class VectorA
  {
        left<*> mul(VectorB);
        left<-> whatever(int);
        left<.> dot(VectorB);
        right<.> dot(VectorB);
  }

 This way you don't have to special case access to class member




properties.

 If you give programs to much power, some are likly to abuse it.


 Hmm, I dunno, that is more concise, but it seems a little harder to
 understand.


I really don't care that much. Whatever is writeable, readable, doesn't
cause specail cases, easy to learn and effecient.

Acually when I first used C++ (a few years ago now) I tried to make an
operator like this...
class VectorA
{
      * (VectorB);
      - (int);
      . (VectorB);
}

...but of course there are problems with that such as the right/left rules.



 Aug 01 2002



prev sibling  parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk>  writes:


Hi,

"Jonathan Andrew" <jon ece.arizona.edu> wrote in message
news:3D48D3BE.404 ece.arizona.edu...

        operator<.>(VectorA, VectorB);
        .... etc.


 True, <> would be a good choice.


Not really, considering the operators "<", ">", "<<", ">>", etc.
"operator<<>" would be recognized by the lexer as the three tokens
"operator", "<<", and ">", thereby introducing the need for extra spacing as
in "operator< < >" ("<>" is a token recognized by the lexer too). Its the
same problem as with templates in C++ - let us learn from it.

Regards,
Martin M. Pedersen



 Aug 01 2002



 next sibling parent  Jonathan Andrew <jon ece.arizona.edu>  writes:


"Martin M. Pedersen" wrote:


 Hi,

 "Jonathan Andrew" <jon ece.arizona.edu> wrote in message
 news:3D48D3BE.404 ece.arizona.edu...

        operator<.>(VectorA, VectorB);
        .... etc.


 True, <> would be a good choice.


 Not really, considering the operators "<", ">", "<<", ">>", etc.
 "operator<<>" would be recognized by the lexer as the three tokens
 "operator", "<<", and ">", thereby introducing the need for extra spacing as
 in "operator< < >" ("<>" is a token recognized by the lexer too). Its the
 same problem as with templates in C++ - let us learn from it.

 Regards,
 Martin M. Pedersen


Hmm, fair enough, I guess we need to invent a keyboard with some
new brackets =)

If anything though, I think this whole thread has shown me that built-in
vector support in the language would be greatly appreciated!



 Aug 01 2002



prev sibling  parent reply Pavel Minayev <evilone omen.ru>  writes:


On Thu=2C 1 Aug 2002 17=3A29=3A48 +0100 =22Martin M=2E Pedersen=22 
=3Cmmp=40www=2Emoeller-pedersen=2Edk=3E wrote=3A

=3E Not really=2C considering the operators =22=3C=22=2C =22=3E=22=2C
=22=3C=3C=22=2C =22=3E=3E=22=2C etc=2E
=3E =22operator=3C=3C=3E=22 would be recognized by the lexer as the three tokens
=3E =22operator=22=2C =22=3C=3C=22=2C and =22=3E=22=2C thereby introducing the
need for extra spacing as
=3E in =22operator=3C =3C =3E=22 =28=22=3C=3E=22 is a token recognized by the
lexer too=29=2E Its the
=3E same problem as with templates in C++ - let us learn from it=2E

I think round braces are the best choice=2E When grouped properly=2C they
look just alright=3A

=09vector operator=28+=29 =28vector a=2C vector b=29
=09{
=09=09=2E=2E=2E
=09}



 Aug 01 2002



  parent reply "anderson" <anderson firestar.com.au>  writes:


Just stay with the brackets then. As I said, is didn't think <> was a good
option but all other brackets are in uses with C++ so I guess it's the only
option. At least it's better then without.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374700137667593 news.digitalmars.com...
On Thu, 1 Aug 2002 17:29:48 +0100 "Martin M. Pedersen"
<mmp www.moeller-pedersen.dk> wrote:


 Not really, considering the operators "<", ">", "<<", ">>", etc.
 "operator<<>" would be recognized by the lexer as the three tokens
 "operator", "<<", and ">", thereby introducing the need for extra spacing


as

 in "operator< < >" ("<>" is a token recognized by the lexer too). Its the
 same problem as with templates in C++ - let us learn from it.


I think round braces are the best choice. When grouped properly, they
look just alright:

vector operator(+) (vector a, vector b)
{
...
}



 Aug 01 2002



  parent reply Patrick Down <pat codemoon.com>  writes:


"anderson" <anderson firestar.com.au> wrote in
news:aickhl$peh$1 digitaldaemon.com: 


 
 vector operator(+) (vector a, vector b)
 {
 ...
 }


vector operator"+"(vector a, vector b)
{
}



 Aug 01 2002



  parent reply "anderson" <anderson firestar.com.au>  writes:


"Patrick Down" <pat codemoon.com> wrote in message
news:Xns925DCD940507patcodemooncom 63.105.9.61...

 "anderson" <anderson firestar.com.au> wrote in
 news:aickhl$peh$1 digitaldaemon.com:


 vector operator(+) (vector a, vector b)
 {
 ...
 }


 vector operator"+"(vector a, vector b)
 {
 }


That's an idea.

<babble> - Parhaps you can get some ideas from this

Come to think of it I remember a language (I thing VB) that put variables
with spaces in square brackets like:

[go to the shops] = [go to the shops] + 1

If course you couldn't use square brackets in D, but perhaps the same symbol
could be used for spaces in words as well.

perhaps


 vector _+_ (vector a, vector b)
{
}

and for functions with spaces

int _function with space_ () {}

but "_" may not stand out enough so I'd recommend something else.

Personally I'd really like it if the operator keyword could be left out
all-together but I don't think that would get though the consensus.

//Perhaps
vector a+b (vector a, vector b)
{
}

and for reverse

vector b+a (vector b, vector a)
{
}

or (but then things get difficult to determine order)

vector (vector b)+(vector a)
{
}


But I'd still like it to be part of the class object as well. It probably
should be a constructor come to think of it.

//Is there any need for reversing here?
this (vector b) + (vector a)
{

}

//int + vector
this (int b) + (vector a)
{

}

//vector + int
this (vector b) + (int a)
{

}

//That is simular to a global method but it's more part of the object

//However, if you have two classes with the same inputs, how do you
determine which one to use
// I'd suggest explictily telling it like when there is a problem (hopefully
rare - and in any case casting could be used):

int a;
vector b;
vector C;

vectorB new, new2;

new = a + b; //Uses vectorB method
new2 = a + vector(+) c;  //Uses vector's method

or

new = a + b; //Uses vectorB method
new2 = a + vector.+ c; //Uses vector's method

//But then you'll still have precedence problems (for example if you want to
work from backwards)
//Parhaps syntax from EBNF (Extended Backus-Naur form) - Walter should be
familiar with this,
//could be used in some way. For anyone else, it's a way of discribing
syntax like the complier does.
//Such as operator precedence and associativity. I don't have any ideas
there (yet).



 Aug 01 2002



  parent reply "Sean L. Palmer" <seanpalmer earthlink.net>  writes:


If operator overloading makes it into D, one of the cool things in C++ is
the Spirit parser generator ( spirit.sourceforge.net ) which implements
quasi-EBNF in C++ using operator overloading.  So to avoid some of the
problems they had, it'd be nice if there were support for postfix * and
postfix +.

But there's already enough ambiguity with * to cause your head to spin.

Sean

"anderson" <anderson firestar.com.au> wrote in message
news:aid6lp$1cuc$1 digitaldaemon.com...

 //But then you'll still have precedence problems (for example if you want


to

 work from backwards)
 //Parhaps syntax from EBNF (Extended Backus-Naur form) - Walter should be
 familiar with this,
 //could be used in some way. For anyone else, it's a way of discribing
 syntax like the complier does.
 //Such as operator precedence and associativity. I don't have any ideas
 there (yet).





 Aug 03 2002



  parent reply "anderson" <anderson firestar.com.au>  writes:


I was thing parhaps precedence could be done with a number.

this a+b 5(vector a, vector b); //Precidence level 5
this b+a 5(vector a, vector b); //Precidence level 5 (reverse)
this z*x 4(vector z, vector x); //Precedence level 4

//Of course there would be a default precedence, so the numbers should only
be used by the experts

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:aig81s$21jv$1 digitaldaemon.com...

 If operator overloading makes it into D, one of the cool things in C++ is
 the Spirit parser generator ( spirit.sourceforge.net ) which implements
 quasi-EBNF in C++ using operator overloading.  So to avoid some of the
 problems they had, it'd be nice if there were support for postfix * and
 postfix +.

 But there's already enough ambiguity with * to cause your head to spin.

 Sean


That also. Except, parhaps that could not be done on the operator level
parhaps something like

= prefix(+ X Y)
= postfix(X Y -)


 "anderson" <anderson firestar.com.au> wrote in message
 news:aid6lp$1cuc$1 digitaldaemon.com...

 //But then you'll still have precedence problems (for example if you




want

 to

 work from backwards)
 //Parhaps syntax from EBNF (Extended Backus-Naur form) - Walter should




be

 familiar with this,
 //could be used in some way. For anyone else, it's a way of discribing
 syntax like the complier does.
 //Such as operator precedence and associativity. I don't have any ideas
 there (yet).







 Aug 03 2002



 next sibling parent reply Pavel Minayev <evilone omen.ru>  writes:


On Sat, 3 Aug 2002 20:49:30 +0800 "anderson" <anderson firestar.com.au> wrote:


 I was thing parhaps precedence could be done with a number.
 
 this a+b 5(vector a, vector b); //Precidence level 5
 this b+a 5(vector a, vector b); //Precidence level 5 (reverse)
 this z*x 4(vector z, vector x); //Precedence level 4
 
 //Of course there would be a default precedence, so the numbers should only
 be used by the experts


I think that user-defined operator precedence is just too complex,
and mostly unused feature. Does it really worth Walter's time to
spend to implement it?



 Aug 03 2002



 next sibling parent  "anderson" <anderson firestar.com.au>  writes:


Your probably right.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374717849229282 news.digitalmars.com...

 On Sat, 3 Aug 2002 20:49:30 +0800 "anderson" <anderson firestar.com.au>


wrote:

 I was thing parhaps precedence could be done with a number.

 this a+b 5(vector a, vector b); //Precidence level 5
 this b+a 5(vector a, vector b); //Precidence level 5 (reverse)
 this z*x 4(vector z, vector x); //Precedence level 4

 //Of course there would be a default precedence, so the numbers should




only

 be used by the experts


 I think that user-defined operator precedence is just too complex,
 and mostly unused feature. Does it really worth Walter's time to
 spend to implement it?





 Aug 03 2002



prev sibling  parent  "Walter" <walter digitalmars.com>  writes:


"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374717849229282 news.digitalmars.com...

 I think that user-defined operator precedence is just too complex,
 and mostly unused feature. Does it really worth Walter's time to
 spend to implement it?


I think it's not a good idea to implement. For one thing, it breaks the idea
of separating the syntactical from the semantic analysis.



 Aug 08 2002



prev sibling  parent reply "anderson" <anderson firestar.com.au>  writes:


"anderson" <anderson firestar.com.au> wrote in message
news:aigj6n$2d5d$1 digitaldaemon.com...
I was thinking precedence could be done with a number parhaps.

 this a+b 5(vector a, vector b); //Precidence level 5
 this b+a 5(vector a, vector b); //Precidence level 5 (reverse)
 this z*x 4(vector z, vector x); //Precedence level 4

 //Of course there would be a default precedence, so the numbers should


only

 be used by the experts





 Aug 03 2002



  parent  user domain.invalid  writes:


I think the precedence for the operator, which way it runs (left to 
right, or vice versa), and whether it is a postfix, prefix, or not 
should be left to the default settings. If it's a left -> right 
operator, the operator function for the object on the left is called. It 
could be defined like this:

class myClass {
	int w = 0, x = 5;
	operator(+, int i) {return w + x + i;} // the operator is passed as the 
first argument to operator function
	operator(+, myClass i) {return w + x + i.w + i.x } // the call to 
operator function is chosen by which operator is used and w/ which data type
}



 Aug 23 2002



prev sibling  parent reply Juarez Rudsatz <juarez nowhere.com>  writes:


"anderson" <anderson firestar.com.au> wrote in news:aia87q$2m8d$1
 digitaldaemon.com:


 No, I agree with you. I was thinking (to stop it looking pointerish) ...
 
  class Vector
  {
        operator<*>(VectorA, VectorB);
        operator<->(VectorA, int);
        operator<.>(VectorA, VectorB);
        .... etc.
  }
 Or another symbol because () makes it look like a weird function (but is
 better then without).



Why not use the keyword and type already available in language :

Class Vector
{
    	void add (int A) {}      	// V + 1
    	int add () {}     	    	// 1 + A
}



 Aug 01 2002



  parent reply Jonathan Andrew <jon ece.arizona.edu>  writes:


Juarez Rudsatz wrote:


 "anderson" <anderson firestar.com.au> wrote in news:aia87q$2m8d$1
  digitaldaemon.com:


 No, I agree with you. I was thinking (to stop it looking pointerish) ...

  class Vector
  {
        operator<*>(VectorA, VectorB);
        operator<->(VectorA, int);
        operator<.>(VectorA, VectorB);
        .... etc.
  }
 Or another symbol because () makes it look like a weird function (but is
 better then without).


 Why not use the keyword and type already available in language :

 Class Vector
 {
         void add (int A) {}             // V + 1
         int add () {}                   // 1 + A
 }


This keeps you from being able to define new symbols to use, and
sometimes there are cases where it would be nice to use symbols
that don't necessarily represent adding, so forth.
For example, if you had some kind of class for a signal function,
and you wanted * to represent convolution, you wouldn't want to
use a function called mul() to represent that operation, even though
it uses the same symbol. (on a keyboard at least)



 Aug 01 2002



 next sibling parent  Juarez Rudsatz <juarez nowhere.com>  writes:


Jonathan Andrew <jon ece.arizona.edu> escreveu em news:3D497E7A.F479D5B3
 ece.arizona.edu:


 This keeps you from being able to define new symbols to use, and
 sometimes there are cases where it would be nice to use symbols
 that don't necessarily represent adding, so forth.
 For example, if you had some kind of class for a signal function,
 and you wanted * to represent convolution, you wouldn't want to
 use a function called mul() to represent that operation, even though
 it uses the same symbol. (on a keyboard at least)
 


I have read another post which speak about having not the operation but 
the symbol used:


 Maybe something like
 class Vector
 {
       static operator(*) cross(VectorA, VectorB);
       static operator(*) mul(VectorA, int);
       static operator(.) dot(VectorA, VectorB);
       .... etc.
 }
 



In this example, the compiler can, without many problems, associate the 
symbol "+" with the identifier "cross". There are no need of specify it 
in all operator declaration.

And another post which specify a serious problem:


 A better approach would be to simply disallow overloading the global
 operators, and say "no" to overloading the syntax:
 
     1 + A;
 
 An alternative is for the compiler to rewrite (1+A) as (A+1) and then
 look for an operator+ overload, but that can lead to trouble for (A+B)
 where both A and B overload operator+.
 


But this have a problem


 There are mathmatical systems where A+B != B+A.


In this example, maybe could solve by making the signal operator 
ordinary procedures and funcions (void and <type>).

Rewriting all of this we could have:

class someType
{
    	override void cross(int i)
    	{
    	    	// this will take care of expressions like
    	    	// A + 1
    	}
    	override int cross()
    	{
    	    	// this will take care of expressions like
    	    	// 1 + A
    	}
}

And all of this could be writed in two forms:

A := A + 1;

or 

A.cross(1 + A.cross());

--
dmd -JR



 Aug 01 2002



prev sibling  parent  "anderson" <anderson firestar.com.au>  writes:


This is a slightly different question then this line, but still in the same
subject matter. In C++ I always had trouble accessing the hidden datatypes
of the other member. If I didn't have direct access to some variable I'd
have to write a function member so that I could access it (or even worse
make the variable public). While is ok in some cases, in others it breaks
the structure of the data abstraction, allowing access to members that
shouldn't be even scene.

Perhaps using static (with full access to both members privates) is the
solution to this, but I recon there may be some better idea. Parhaps, and
I'm by no way clear on the details, could add some type of privlage system
on member functions so that we can specify which functions have access to
which members (or something, I'm not clear on the idea here). Parhaps I
could be simular to java packages. Parhaps a class could belong to seveal
prilage groups. Or parhaps theres some other better idea. I would really
like the solution to this to be non-special case. Parhaps D already has
something.

"Jonathan Andrew" <jon ece.arizona.edu> wrote in message
news:3D497E7A.F479D5B3 ece.arizona.edu...

 Juarez Rudsatz wrote:


 "anderson" <anderson firestar.com.au> wrote in news:aia87q$2m8d$1
  digitaldaemon.com:


 No, I agree with you. I was thinking (to stop it looking pointerish)






...

  class Vector
  {
        operator<*>(VectorA, VectorB);
        operator<->(VectorA, int);
        operator<.>(VectorA, VectorB);
        .... etc.
  }
 Or another symbol because () makes it look like a weird function (but






is

 better then without).


 Why not use the keyword and type already available in language :

 Class Vector
 {
         void add (int A) {}             // V + 1
         int add () {}                   // 1 + A
 }


 This keeps you from being able to define new symbols to use, and
 sometimes there are cases where it would be nice to use symbols
 that don't necessarily represent adding, so forth.
 For example, if you had some kind of class for a signal function,
 and you wanted * to represent convolution, you wouldn't want to
 use a function called mul() to represent that operation, even though
 it uses the same symbol. (on a keyboard at least)





 Aug 01 2002



prev sibling  parent  C.R.Chafer <blackmarlin nospam.asean-mail.com>  writes:


Jonathan Andrew wrote:


 
 Maybe something like
 class Vector
 {
       static operator(*) cross(VectorA, VectorB);
       static operator(*) mul(VectorA, int);
       static operator(.) dot(VectorA, VectorB);
       .... etc.
 }
 
 This way, those who don't like operator overloading could
 still call the functions by name, i.e. cross(), dot() etc.
 and you could specify which symbol to use also.
 Just an idea,
   -Jon


I like the idea - especially as it is similar to the method I use in my 
language (oomic) .. however in the latter case the syntax is different
so you would get:

        function subtract Vector as ( a - b )
        ;;      a       Vector
        ,       b       Vector
        { ... }
        function negate Vector as ( - a )
        ;;      a       Vector
        { ... }

The main advantage here is that the equation parser can be used to parse
the operator overloading specifier.
Here of course there is no need to specify left / right / binary association
(though post fix operators are not allowed in the current version).
Maybe this idea could be adapted for D?

C 2002/8/1



 Aug 01 2002



prev sibling  parent reply "Walter" <walter digitalmars.com>  writes:


Yes, but then virtual calls won't work for them. Sigh.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374676619595486 news.digitalmars.com...
class Vector
{
...
static operator* (Vector a, Vector b) { ... }
static operator* (Vector a, int b) { ... }
}
Short and clear.



 Aug 03 2002



  parent reply Pavel Minayev <evilone omen.ru>  writes:


On Sat=2C 3 Aug 2002 14=3A49=3A29 -0700 =22Walter=22
=3Cwalter=40digitalmars=2Ecom=3E wrote=3A

=3E Yes=2C but then virtual calls won't work for them=2E Sigh=2E

If one REALLY needs a virtual operator =28so far I didn't=29=2C he could
just wrap a function call into it=3A

=09class Foo
=09{
=09=09Foo op=5Fmul=28Foo b=29 { =2E=2E=2E }=09=2F=2F this one is virtual!
=09=09Foo operator=28*=29 =28Foo a=2C Foo b=29 { return a=2Eop=5Fmul=28b=29=3B }
=09}

Overloaded operators are mostly used for vectors=2C matrices=2C and
alike=2C where perfomance is typically more important=2E There is
no sence of having a virtual operator+ for vectors=2E Could anybody
show an example where virtual operators are really needed=3F



 Aug 03 2002



 next sibling parent  "anderson" <anderson firestar.com.au>  writes:


But why not simply have the function call in the first place as the
operator?

"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374721052143982 news.digitalmars.com...
On Sat, 3 Aug 2002 14:49:29 -0700 "Walter" <walter digitalmars.com> wrote:


 Yes, but then virtual calls won't work for them. Sigh.


If one REALLY needs a virtual operator (so far I didn't), he could
just wrap a function call into it:

class Foo
{
Foo op_mul(Foo b) { ... } // this one is virtual!
Foo operator(*) (Foo a, Foo b) { return a.op_mul(b); }
}

Overloaded operators are mostly used for vectors, matrices, and
alike, where perfomance is typically more important. There is
no sence of having a virtual operator+ for vectors. Could anybody
show an example where virtual operators are really needed?



 Aug 03 2002



prev sibling  parent reply "Walter" <walter digitalmars.com>  writes:


"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374721052143982 news.digitalmars.com...

Overloaded operators are mostly used for vectors, matrices, and
alike, where perfomance is typically more important. There is
no sence of having a virtual operator+ for vectors. Could anybody
show an example where virtual operators are really needed?


The compare operator when building, say, a generic array sorter.



 Aug 04 2002



 next sibling parent  Pavel Minayev <evilone omen.ru>  writes:


On Sun, 4 Aug 2002 08:15:32 -0700 "Walter" <walter digitalmars.com> wrote:


 The compare operator when building, say, a generic array sorter.


It can always be implemented as a virtual cmp() function.
Besided, you won't need it to be virtual if that array sorter would be 
templated.



 Aug 04 2002



prev sibling  parent reply "anderson" <anderson firestar.com.au>  writes:


Just wondering what the argument against virtual static members is? I've
never read anything against them in books. I'm sure there's a good reason
they weren't implemented in C++. So what it the reasoning against virtual
static members?

Thanks



 Aug 04 2002



 next sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net>  writes:


Because it doesn't make sense to call a static method through an object
reference?  But how else do you get the compiler to "figure out" which
version of the function to call?  Seems you either want a static function
(non-virtual) or a virtual member function.

How would you use one if you had the capability?

Sean

"anderson" <anderson firestar.com.au> wrote in message
news:aikj9d$2bh1$1 digitaldaemon.com...

 Just wondering what the argument against virtual static members is? I've
 never read anything against them in books. I'm sure there's a good reason
 they weren't implemented in C++. So what it the reasoning against virtual
 static members?

 Thanks





 Aug 05 2002



  parent  "anderson" <anderson firestar.com.au>  writes:


Class ClassA
{
    virtual static int Var;

    virtual static void Something();
}

Class ClassB : ClassA
{
    virtual static void Something();
}

And you wouldn't use a just an object reference, you'd use the class name.

ClassA.Something();
ClassB.Something();

ClassA.Var = 11; //Class a's Var has 11
ClassB.Var = 10; //Class b's Var has 10 and class A's var still has 11

Although using a object reference may make sense sometimes.

Basicly to deal with properties and methods that are one per class not per
class and all child classes as well.  It treats a class as the group of
objects on one level.

There are work-arounds, but why use them when you could use the proper
thing.

I'm sure there's gota be a better reason then that. Parhaps it's to hard to
implement in the complier, parhaps it's ineffecient, parhaps it should be
defined using a parallel object sturcture.

Here's a few other newsgroup links that portray the same opinion (I couldn't
find any good reasons against so that's why I'm asking).

http://dbforums.com/archive/89/2001/06/1/65121
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&th=ca8b
a27e7944e9ab&rnum=1
http://groups.google.com/groups?q=%22static+virtual+methods%22+%22C%2B%2B%22
&hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=3904%40lulea.trab.se&rnum=5


"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ailbl9$18sd$1 digitaldaemon.com...

 Because it doesn't make sense to call a static method through an object
 reference?  But how else do you get the compiler to "figure out" which
 version of the function to call?  Seems you either want a static function
 (non-virtual) or a virtual member function.

 How would you use one if you had the capability?

 Sean

 "anderson" <anderson firestar.com.au> wrote in message
 news:aikj9d$2bh1$1 digitaldaemon.com...

 Just wondering what the argument against virtual static members is? I've
 never read anything against them in books. I'm sure there's a good




reason

 they weren't implemented in C++. So what it the reasoning against




virtual

 static members?

 Thanks







 Aug 05 2002



prev sibling  parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com>  writes:


"anderson" <anderson firestar.com.au> wrote in message
news:aikj9d$2bh1$1 digitaldaemon.com...


 Just wondering what the argument against virtual static members is? I've
 never read anything against them in books. I'm sure there's a good reason
 they weren't implemented in C++. So what it the reasoning against virtual
 static members?


   What you mean is having a global function that can dynamically dispatch
according to an object's real type. That can definitely be done (see Mozart
in SourceForge), but it is a bit complicated. In C++ and D, dynamic dispatch
is designed for virtual function tables, although that particular
implementation is not necessarily used. This was done by requiring every
class to know, beforehand, all the functions it'll dynamically dispatch to.
The "object.function()" syntax can be seen as just syntactic sugar, really.
Allowing arbitrary virtual functions to be added outside of the class would
require a different method. The upside of this is that, if such a method is
implemented, multiple dynamic dispatch comes naturally (that's why Mozart
supports it).

   It would be a worthwhile addition to the language, except for all the
complication (which is quite a bit).

Salutaciones,
                         JCAB



 Aug 13 2002



  parent  "anderson" <anderson firestar.com.au>  writes:


Thanks.

"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message
news:ajcd0u$2g3a$1 digitaldaemon.com...

 "anderson" <anderson firestar.com.au> wrote in message
 news:aikj9d$2bh1$1 digitaldaemon.com...


 Just wondering what the argument against virtual static members is? I've
 never read anything against them in books. I'm sure there's a good




reason

 they weren't implemented in C++. So what it the reasoning against




virtual

 static members?


    What you mean is having a global function that can dynamically dispatch
 according to an object's real type. That can definitely be done (see


Mozart

 in SourceForge), but it is a bit complicated. In C++ and D, dynamic


dispatch

 is designed for virtual function tables, although that particular
 implementation is not necessarily used. This was done by requiring every
 class to know, beforehand, all the functions it'll dynamically dispatch


to.

 The "object.function()" syntax can be seen as just syntactic sugar,


really.

 Allowing arbitrary virtual functions to be added outside of the class


would

 require a different method. The upside of this is that, if such a method


is

 implemented, multiple dynamic dispatch comes naturally (that's why Mozart
 supports it).

    It would be a worthwhile addition to the language, except for all the
 complication (which is quite a bit).

 Salutaciones,
                          JCAB





 Aug 13 2002