www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - behavior of char []

reply Charlie <Charlie_member pathlink.com> writes:
Egon recently posted a tutorial on std.streams
(http://www.dsource.org/tutorials/index.php?show_example=87 )


in it he uses this

// paraphrased
char [] input = readInput();
input.toupper();

Where toupper is defined in std.string as char [] toUpper(char [] );

After some playing around it seems that any function expecting a char [] as its
first argument, can be turned into a method !

int x = input.toInt();

And even user defined functions!

char [] something(char [] x ) { return x ~ " manipulated"; }

input.something();

!!

This is very cool I think, what about enabling this for any object / primitive ?
What do you guys think ?  I can see some drawbacks, but i think it could extend
re-usability by alowing for an OO shortcut for normal procedural functions.

Im not sure when this got slipped in (maybe always this way ? ) , seems Walter's
trying to keep us on our toes.

Thanks,
Charlie
May 16 2004
next sibling parent J C Calvarese <jcc7 cox.net> writes:
Charlie wrote:
 Egon recently posted a tutorial on std.streams
 (http://www.dsource.org/tutorials/index.php?show_example=87 )
 
 
 in it he uses this
 
 // paraphrased
 char [] input = readInput();
 input.toupper();
 
 Where toupper is defined in std.string as char [] toUpper(char [] );
 
 After some playing around it seems that any function expecting a char [] as its
 first argument, can be turned into a method !
 
 int x = input.toInt();
 
 And even user defined functions!
 
 char [] something(char [] x ) { return x ~ " manipulated"; }
 
 input.something();
 
 !!
 
 This is very cool I think, what about enabling this for any object / primitive
?
 What do you guys think ?  I can see some drawbacks, but i think it could extend
 re-usability by alowing for an OO shortcut for normal procedural functions.
 
 Im not sure when this got slipped in (maybe always this way ? ) , seems
Walter's
 trying to keep us on our toes.
 
 Thanks,
 Charlie

Right. I think it'd be cool if this example worked where int has a squareit property (not that I'd actually call a function "squareit"). Everything could have a toString property by importing std.string. char[] alwaysWhatever(char[] c) { return "alwaysWhatever" ~ c; } int squareit(int i) { return i * i; } void main() { char[] d = "Hi"; int i = 9; /* works */ printf("%.*s\n", d.alwaysWhatever()); /* doesn't work... */ printf("%.*s\t%d\n", d.alwaysWhatever(), i.squareit()); } -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
May 16 2004
prev sibling next sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
Is this another of those great D features that isn't mentioned anywhere?

So i tried this:
short[] movestack;

static int sum(short[] arr,int index)
{
      int suma=0;
      for(int i=0;i<arr.length;i++)
      {
           suma+=colors[arr[i]][index];
      }
      return suma;
}

And now i can do
   r=movestack.sum(0)/movestack.length;
instead of:
   r=sum(movestack,0)/movestack.length;

So it works not only for char[]but also for all arrays?
Walter please make it work for non-array types
because it looks like avery useful feature :)


"Charlie" <Charlie_member pathlink.com> wrote in message
news:c89ap4$10go$1 digitaldaemon.com...
 Egon recently posted a tutorial on std.streams
 (http://www.dsource.org/tutorials/index.php?show_example=87 )


 in it he uses this

 // paraphrased
 char [] input = readInput();
 input.toupper();

 Where toupper is defined in std.string as char [] toUpper(char [] );

 After some playing around it seems that any function expecting a char []

 first argument, can be turned into a method !

 int x = input.toInt();

 And even user defined functions!

 char [] something(char [] x ) { return x ~ " manipulated"; }

 input.something();

 !!

 This is very cool I think, what about enabling this for any object /

 What do you guys think ?  I can see some drawbacks, but i think it could

 re-usability by alowing for an OO shortcut for normal procedural

 Im not sure when this got slipped in (maybe always this way ? ) , seems

 trying to keep us on our toes.

 Thanks,
 Charlie

May 17 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Charlie wrote:
 Egon recently posted a tutorial on std.streams
 (http://www.dsource.org/tutorials/index.php?show_example=87 )
 
 in it he uses this
 
 // paraphrased
 char [] input = readInput();
 input.toupper();

This bit of "magic" frightens me terribly. It seems handy at first glance, but it smells like an arbitrarily added bit of syntactic sugar that is only useful for a handful of problems, to say nothing for the ease with which it could be misused. Should this work with all types? eek. -- andy
May 17 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Andy Friesen wrote:

 Charlie wrote:
 Egon recently posted a tutorial on std.streams
 (http://www.dsource.org/tutorials/index.php?show_example=87 )
 
 in it he uses this
 
 // paraphrased
 char [] input = readInput();
 input.toupper();

This bit of "magic" frightens me terribly. It seems handy at first glance, but it smells like an arbitrarily added bit of syntactic sugar that is only useful for a handful of problems, to say nothing for the ease with which it could be misused. Should this work with all types? eek.

Sounds pretty much like my remark, though I'm somewhat more neutral about it: There are languages, where a.f(b,c) is generally syntactic sugar for f(a,b,c) In D, this sounds like a huge step, but it might not be as far away from the current situation as it look at first sight. Internally, both calls are identical already. The only question would be how to decide in case of a collision. The big advantage I see there, is that you can finally stop thinking about whether to make a certain feature a method or a free function. There would not be any difference between str.length, str.length() or length(str) It is a big step for the language, but it might also be a huge simplification of concepts.
May 17 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Norbert Nemec wrote:

 The big advantage I see there, is that you can finally stop thinking about
 whether to make a certain feature a method or a free function. There would
 not be any difference between str.length, str.length() or length(str)

The benefits are there, I agree. I am more concerned with just how easy this is to misuse. I would be happier if the primitive types had a stable, well-known set of operations defined within the language (and/or standard library). I can see myself looking at code later and thinking "what the hell, strings don't do that", then later realizing that it's probably a free function defined... someplace. However, I am having a hard time rationalizing my opinion. I may need to reevaluate it. -- andy
May 17 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Andy Friesen wrote:

 Norbert Nemec wrote:
 
 The big advantage I see there, is that you can finally stop thinking
 about whether to make a certain feature a method or a free function.
 There would not be any difference between str.length, str.length() or
 length(str)

The benefits are there, I agree. I am more concerned with just how easy this is to misuse. I would be happier if the primitive types had a stable, well-known set of operations defined within the language (and/or standard library). I can see myself looking at code later and thinking "what the hell, strings don't do that", then later realizing that it's probably a free function defined... someplace. However, I am having a hard time rationalizing my opinion. I may need to reevaluate it.

I don't quite understand your position: I would guess that everyone agrees with your statement as long as you include the words "and/or standard library" - of course stuff like .length must be well defined, but I believe that the language should try to define only the absolutely bare minimum and leave as much as possible to the library, unless there are good reasons (like performance or special syntax) to do otherwise. I guess, .length is part of the minimal interface of arrays, so this one should really go into the language definition. Of course, D needs a well-defined standard library to work. And if you override parts of that library, you should really know what you are doing. But that still is the allow-anyone-to-shoot-himself-in-the-foot attitude of D...
May 17 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Norbert Nemec wrote:
 I don't quite understand your position: I would guess that everyone agrees
 with your statement as long as you include the words "and/or standard
 library" - of course stuff like .length must be well defined, but I believe
 that the language should try to define only the absolutely bare minimum and
 leave as much as possible to the library, unless there are good reasons
 (like performance or special syntax) to do otherwise. I guess, .length is
 part of the minimal interface of arrays, so this one should really go into
 the language definition.

Take std.string for example. A lot of the functions there behave, and are conveniently used as though they were methods of char[]. That's all well and good, but, if anybody can add to those operations just by defining a function, the 'interface' for char[] depends purely on what imports are in the current scope.
 Of course, D needs a well-defined standard library to work. And if you
 override parts of that library, you should really know what you are doing.
 But that still is the allow-anyone-to-shoot-himself-in-the-foot attitude of
 D...

I like to think of D's approach as "allow anyone to shoot himself in the foot if he's really sure that's what he wants, but make it hard to do accidentally". -- andy
May 17 2004
parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Andy Friesen wrote:

 Norbert Nemec wrote:
 I don't quite understand your position: I would guess that everyone
 agrees with your statement as long as you include the words "and/or
 standard library" - of course stuff like .length must be well defined,
 but I believe that the language should try to define only the absolutely
 bare minimum and leave as much as possible to the library, unless there
 are good reasons (like performance or special syntax) to do otherwise. I
 guess, .length is part of the minimal interface of arrays, so this one
 should really go into the language definition.

Take std.string for example. A lot of the functions there behave, and are conveniently used as though they were methods of char[]. That's all well and good, but, if anybody can add to those operations just by defining a function, the 'interface' for char[] depends purely on what imports are in the current scope.

Does it hurt if an interface is freely extendable? If you don't use a feature, you don't have to worry if it is there. The only problem that might occur is, that you want to use a feature and don't know what to import for it. But that problem is the same whether the feature is called via .something or via something() One only has to rethink when coming from C++, where .something always is a feature defined within a class or struct. But that has already changed with the introduction of properties of fundamental types.
 Of course, D needs a well-defined standard library to work. And if you
 override parts of that library, you should really know what you are
 doing. But that still is the allow-anyone-to-shoot-himself-in-the-foot
 attitude of D...

I like to think of D's approach as "allow anyone to shoot himself in the foot if he's really sure that's what he wants, but make it hard to do accidentally".

True. Sorry for the abbreviated citation...
May 17 2004
prev sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Before giving my opinion on this feature, I would really like to see it
documented. It certainly might be a neat thing, but just crying "Please
make this work in general!" sounds a bit short-sighted, as long as it is
not clear, what "in general" would mean in detail and how it would affect
the overall language.



Charlie wrote:

 Egon recently posted a tutorial on std.streams
 (http://www.dsource.org/tutorials/index.php?show_example=87 )
 
 
 in it he uses this
 
 // paraphrased
 char [] input = readInput();
 input.toupper();
 
 Where toupper is defined in std.string as char [] toUpper(char [] );
 
 After some playing around it seems that any function expecting a char []
 as its first argument, can be turned into a method !
 
 int x = input.toInt();
 
 And even user defined functions!
 
 char [] something(char [] x ) { return x ~ " manipulated"; }
 
 input.something();
 
 !!
 
 This is very cool I think, what about enabling this for any object /
 primitive ?
 What do you guys think ?  I can see some drawbacks, but i think it could
 extend re-usability by alowing for an OO shortcut for normal procedural
 functions.
 
 Im not sure when this got slipped in (maybe always this way ? ) , seems
 Walter's trying to keep us on our toes.
 
 Thanks,
 Charlie

May 17 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:c89tqh$1v1r$1 digitaldaemon.com...
 Before giving my opinion on this feature, I would really like to see it
 documented. It certainly might be a neat thing, but just crying "Please
 make this work in general!" sounds a bit short-sighted, as long as it is
 not clear, what "in general" would mean in detail and how it would affect
 the overall language.

I think this feature has a big potential. For example like J C Calvarese said toString property could be added for built-in types, it would be possible to implement a lot of array helper functions(for example in the standard library), and they could be used in a more natural way: int[] numbers; numbers.deleteAt(index); or as a template: numbers.deleteAt!(int)(index); numbers.find(somenumber); instead of: find(numbers.somenumber); Otherwise these functions would probbably be implemented like static functions of an Array class ant that would be even worse: Array.find(numbers,somenumber); Aray.deleteAt(numbers,index); I know this is only a syntax shugar but it is a great one. By the way this feature allready is implemented but a big problem is that it only works for arrays, such inconsistencies are not good for any language, if a new user sees this to work for char[] or int[] he will also think that it works for other types. Unless for a very good reason this will only be possible to implement for arrays then i agree it shuld be documented and explained. Again i can only say "Please make this work in general" and i don't think it is short-sighted, actually i am looking very far into the possiblities of this feature, but in the case i am wrong i will probbably get good answers and explanations why this isn't a good feature and what possible problems can it cause :)
 Charlie wrote:

 Egon recently posted a tutorial on std.streams
 (http://www.dsource.org/tutorials/index.php?show_example=87 )


 in it he uses this

 // paraphrased
 char [] input = readInput();
 input.toupper();

 Where toupper is defined in std.string as char [] toUpper(char [] );

 After some playing around it seems that any function expecting a char []
 as its first argument, can be turned into a method !

 int x = input.toInt();

 And even user defined functions!

 char [] something(char [] x ) { return x ~ " manipulated"; }

 input.something();

 !!

 This is very cool I think, what about enabling this for any object /
 primitive ?
 What do you guys think ?  I can see some drawbacks, but i think it could
 extend re-usability by alowing for an OO shortcut for normal procedural
 functions.

 Im not sure when this got slipped in (maybe always this way ? ) , seems
 Walter's trying to keep us on our toes.

 Thanks,
 Charlie


May 17 2004
next sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
I just thought of another use of this: One day when DTL comes out
and a lot of containers and algorithms can be used, this synatax sugar
would give us the posiblillity to use an algorithm as if it were a part of
the container class, and also normal arrays would be given features
similar to those of containers.

I could write:
list!(int) c1;
c1.find(3);

and also
int[] c2;
c2.find(3);


"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:c8a3vf$28d7$1 digitaldaemon.com...
 "Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
 news:c89tqh$1v1r$1 digitaldaemon.com...
 Before giving my opinion on this feature, I would really like to see it
 documented. It certainly might be a neat thing, but just crying "Please
 make this work in general!" sounds a bit short-sighted, as long as it is
 not clear, what "in general" would mean in detail and how it would


 the overall language.

I think this feature has a big potential. For example like J C Calvarese said toString property could be added for built-in types, it would be possible to implement a lot of array helper functions(for example in the standard library), and they could be used in a more natural way: int[] numbers; numbers.deleteAt(index); or as a template: numbers.deleteAt!(int)(index); numbers.find(somenumber); instead of: find(numbers.somenumber); Otherwise these functions would probbably be implemented like static functions of an Array class ant that would be even worse: Array.find(numbers,somenumber); Aray.deleteAt(numbers,index); I know this is only a syntax shugar but it is a great one. By the way this feature allready is implemented but a big problem is that it only works for arrays, such inconsistencies are not good for any language, if a new user sees this to work for char[] or int[] he will also think that it

 for other types.

 Unless for a very good reason this will only be possible to implement
 for arrays then i agree it shuld be documented and explained.

 Again i can only say "Please make this work in general" and i don't
 think it is short-sighted, actually i am looking very far into the
 possiblities
 of this feature, but in the case i am wrong i will probbably get good
 answers and explanations why this isn't a good feature and what possible
 problems can it cause :)

 Charlie wrote:

 Egon recently posted a tutorial on std.streams
 (http://www.dsource.org/tutorials/index.php?show_example=87 )


 in it he uses this

 // paraphrased
 char [] input = readInput();
 input.toupper();

 Where toupper is defined in std.string as char [] toUpper(char [] );

 After some playing around it seems that any function expecting a char



 as its first argument, can be turned into a method !

 int x = input.toInt();

 And even user defined functions!

 char [] something(char [] x ) { return x ~ " manipulated"; }

 input.something();

 !!

 This is very cool I think, what about enabling this for any object /
 primitive ?
 What do you guys think ?  I can see some drawbacks, but i think it



 extend re-usability by alowing for an OO shortcut for normal



 functions.

 Im not sure when this got slipped in (maybe always this way ? ) ,



 Walter's trying to keep us on our toes.

 Thanks,
 Charlie



May 17 2004
prev sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Ivan Senji wrote:

 Again i can only say "Please make this work in general" and i don't
 think it is short-sighted, actually i am looking very far into the
 possiblities
 of this feature, but in the case i am wrong i will probbably get good
 answers and explanations why this isn't a good feature and what possible
 problems can it cause :)

It is hard to pinpoint problems without a clear idea what we are talking about. For example: Would a.f(b,c) and f(a,b,c) be absolutely identical in any case? This would make free functions identical to non-virtual functions in C++. It would have to be illegal to define colliding methods and free functions. If you have nested namespaces, this would break existing code without giving any error messages: ------------------ class A { void f() { ... } }; class B { void f(A a) { ... } void x(A a) { f(a); a.f(); } }; ------------------ what would happen in this case? I really like the idea, but as you see, it would have tremendous impact on the language as a whole.
May 17 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
In article <c8ah78$2sd9$1 digitaldaemon.com>, Norbert Nemec says...
Ivan Senji wrote:

 Again i can only say "Please make this work in general" and i don't
 think it is short-sighted, actually i am looking very far into the
 possiblities
 of this feature, but in the case i am wrong i will probbably get good
 answers and explanations why this isn't a good feature and what possible
 problems can it cause :)

It is hard to pinpoint problems without a clear idea what we are talking about. For example: Would a.f(b,c) and f(a,b,c) be absolutely identical in any case? This would make free functions identical to non-virtual functions in C++. It would have to be illegal to define colliding methods and free functions. If you have nested namespaces, this would break existing code without giving any error messages: ------------------ class A { void f() { ... } }; class B { void f(A a) { ... } void x(A a) { f(a); a.f(); } }; ------------------ what would happen in this case? I really like the idea, but as you see, it would have tremendous impact on the language as a whole.

I can't see much of a benefit to allow this on A and B classes, when a person can already achieve this functionality by defining a method. Actually, I suspect it's a bad idea to allow this on classes and structs. I'm also not sure how it should affect fixed arrays. We can already use these tricks with char[] and int[] (and I haven't read any bug reports relating to this yet). I wonder if it'd cause problems to allow this syntax with int, uint, char, bit, etc. I can see some benefits. For example, it might be appealing to people who like this aspect of Java. I'm not saying we NEED this "syntactic sugar", but I like the idea, and I'm curious what the actual downside should be. (Yes, I know everything has a cost, but the cost might be low.) jcc7
May 17 2004
next sibling parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
J C Calvarese wrote:
 I can't see much of a benefit to allow this on A and B classes, when a
 person can already achieve this functionality by defining a method.
 Actually, I suspect it's a bad idea to allow this on classes and structs.
 I'm also not sure how it should affect fixed arrays.

OK, that would be the smaller solution: just make a.something(b,c) syntactic sugar for something(a,b,c) in those cases where a is neither a struct nor a class. That should not cause any trouble, I think. It does not break any existing code. I really start to like that idea. It always seemed somewhat odd to me that certain types have properties, but you could not add others in the library. It would also help answering the question whether properties like .sort might be better moved to the library, since this would not affect the user at all any more.
May 17 2004
prev sibling parent reply Charlie <Charlie_member pathlink.com> writes:
For example, it
might be appealing to people who like this aspect of Java.

Oh does Java do this ? I just tried and couldnt get it to work, but im only 3 days into Java, so its probably something im missing. Charlie In article <c8ajt1$3081$1 digitaldaemon.com>, J C Calvarese says...
In article <c8ah78$2sd9$1 digitaldaemon.com>, Norbert Nemec says...
Ivan Senji wrote:

 Again i can only say "Please make this work in general" and i don't
 think it is short-sighted, actually i am looking very far into the
 possiblities
 of this feature, but in the case i am wrong i will probbably get good
 answers and explanations why this isn't a good feature and what possible
 problems can it cause :)

It is hard to pinpoint problems without a clear idea what we are talking about. For example: Would a.f(b,c) and f(a,b,c) be absolutely identical in any case? This would make free functions identical to non-virtual functions in C++. It would have to be illegal to define colliding methods and free functions. If you have nested namespaces, this would break existing code without giving any error messages: ------------------ class A { void f() { ... } }; class B { void f(A a) { ... } void x(A a) { f(a); a.f(); } }; ------------------ what would happen in this case? I really like the idea, but as you see, it would have tremendous impact on the language as a whole.

I can't see much of a benefit to allow this on A and B classes, when a person can already achieve this functionality by defining a method. Actually, I suspect it's a bad idea to allow this on classes and structs. I'm also not sure how it should affect fixed arrays. We can already use these tricks with char[] and int[] (and I haven't read any bug reports relating to this yet). I wonder if it'd cause problems to allow this syntax with int, uint, char, bit, etc. I can see some benefits. For example, it might be appealing to people who like this aspect of Java. I'm not saying we NEED this "syntactic sugar", but I like the idea, and I'm curious what the actual downside should be. (Yes, I know everything has a cost, but the cost might be low.) jcc7

May 17 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
In article <c8aril$b1t$1 digitaldaemon.com>, Charlie says...
For example, it
might be appealing to people who like this aspect of Java.

Oh does Java do this ? I just tried and couldnt get it to work, but im only 3 days into Java, so its probably something im missing. Charlie

Well, not exactly. What I mean is that Java's String class has a toUpper and toLower that are accessed with a dot: e.g. myString.toUpper. So I exagerated the new way's similarity to Java. It just looks "Javish" to me. jcc7
In article <c8ajt1$3081$1 digitaldaemon.com>, J C Calvarese says...
In article <c8ah78$2sd9$1 digitaldaemon.com>, Norbert Nemec says...
Ivan Senji wrote:

 Again i can only say "Please make this work in general" and i don't
 think it is short-sighted, actually i am looking very far into the
 possiblities
 of this feature, but in the case i am wrong i will probbably get good
 answers and explanations why this isn't a good feature and what possible
 problems can it cause :)

It is hard to pinpoint problems without a clear idea what we are talking about. For example: Would a.f(b,c) and f(a,b,c) be absolutely identical in any case? This would make free functions identical to non-virtual functions in C++. It would have to be illegal to define colliding methods and free functions. If you have nested namespaces, this would break existing code without giving any error messages: ------------------ class A { void f() { ... } }; class B { void f(A a) { ... } void x(A a) { f(a); a.f(); } }; ------------------ what would happen in this case? I really like the idea, but as you see, it would have tremendous impact on the language as a whole.

I can't see much of a benefit to allow this on A and B classes, when a person can already achieve this functionality by defining a method. Actually, I suspect it's a bad idea to allow this on classes and structs. I'm also not sure how it should affect fixed arrays. We can already use these tricks with char[] and int[] (and I haven't read any bug reports relating to this yet). I wonder if it'd cause problems to allow this syntax with int, uint, char, bit, etc. I can see some benefits. For example, it might be appealing to people who like this aspect of Java. I'm not saying we NEED this "syntactic sugar", but I like the idea, and I'm curious what the actual downside should be. (Yes, I know everything has a cost, but the cost might be low.) jcc7


May 17 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
J C Calvarese wrote:
 In article <c8aril$b1t$1 digitaldaemon.com>, Charlie says...
 
For example, it
might be appealing to people who like this aspect of Java.

Oh does Java do this ? I just tried and couldnt get it to work, but im only 3 days into Java, so its probably something im missing. Charlie

Well, not exactly. What I mean is that Java's String class has a toUpper and toLower that are accessed with a dot: e.g. myString.toUpper. So I exagerated the new way's similarity to Java. It just looks "Javish" to me.

Eh? Accessing member methods with a dot is "Javaish"? It's also "D-ish", "C++-ish", "C#-ish", "Pythonesque", "Luarish" and "just about any other OO language"-ish ;). Hauke
May 17 2004
parent J C Calvarese <jcc7 cox.net> writes:
Hauke Duden wrote:

 J C Calvarese wrote:
 
 In article <c8aril$b1t$1 digitaldaemon.com>, Charlie says...

 For example, it
 might be appealing to people who like this aspect of Java.

Oh does Java do this ? I just tried and couldnt get it to work, but im only 3 days into Java, so its probably something im missing. Charlie

Well, not exactly. What I mean is that Java's String class has a toUpper and toLower that are accessed with a dot: e.g. myString.toUpper. So I exagerated the new way's similarity to Java. It just looks "Javish" to me.

Eh? Accessing member methods with a dot is "Javaish"? It's also "D-ish",

Actually, I used the less-common expression "Javish" rather than "Javaish". (Not that it matters.)
 "C++-ish", "C#-ish", "Pythonesque", "Luarish" and "just about any other 
 OO language"-ish ;).
 
 Hauke

Maybe it's my lack of knowledge in C++, C#, Python, Lua, and Smalltalk. :) -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
May 17 2004
prev sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:c8ah78$2sd9$1 digitaldaemon.com...
 Ivan Senji wrote:

 Again i can only say "Please make this work in general" and i don't
 think it is short-sighted, actually i am looking very far into the
 possiblities
 of this feature, but in the case i am wrong i will probbably get good
 answers and explanations why this isn't a good feature and what possible
 problems can it cause :)

It is hard to pinpoint problems without a clear idea what we are talking about. For example: Would a.f(b,c) and f(a,b,c) be absolutely identical in any case? This would make free functions identical to non-virtual functions in C++. It would have to be illegal to define colliding methods and free functions. If you have nested namespaces, this would break existing code without

 any error messages:

 ------------------
 class A {
         void f() { ... }
 };

 class B {
         void f(A a) { ... }

         void x(A a) { f(a); a.f(); }
 };
 ------------------

 what would happen in this case?

 I really like the idea, but as you see, it would have tremendous impact on
 the language as a whole.

The D-way of dealing with be to define a simple rule: either report that the code is ambigous or define a simple rule for example, a.f() first look for f() in a, and then if not found look for f(a). But thinking a little bit more about this i agree with you that it would be good if this worked for non-struct and non-class types. Although it could be useful sometimes with classes also :)
May 17 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Ivan Senji wrote:

The D-way of dealing with be to define a simple rule: either report
that the code is ambigous or define a simple rule for example,
a.f() first look for f() in a, and then if not found look for f(a).

But thinking a little bit more about this i agree with you that it
would be good if this worked for non-struct and non-class types.

Although it could be useful sometimes with classes also :)
  

operators. -- -Anderson: http://badmama.com.au/~anderson/
May 17 2004