Thread overview | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
May 17, 2004 behavior of char [] | ||||
---|---|---|---|---|
| ||||
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 Re: behavior of char [] (and beyond?) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Charlie | 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 17, 2004 Re: behavior of char [] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Charlie | 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 Re: behavior of char [] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Charlie | 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 Re: behavior of char [] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Charlie | 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 Re: behavior of char [] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy Friesen | 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 Re: behavior of char [] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Norbert Nemec | "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 Re: behavior of char [] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ivan Senji | 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 Re: behavior of char [] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ivan Senji | 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 Re: behavior of char [] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Norbert Nemec | 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 |
Copyright © 1999-2021 by the D Language Foundation