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


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




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

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



 OO language"-ish ;).
 
 Hauke









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


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.


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


I'd bet a lot of people want this enabled for class (and primitives) 
operators.

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