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

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/

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

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

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

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.

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

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

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.

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