How about iterating over structures:

myprint(double x) {...}
myprint(int x) {...}

// could be a class .. or an enum!
struct foo {
int a;
double b;
};

foo bar;

// syntax may need adjustment
foreach(alias n, bar) {
my_print(n);
}

Also, (it seems like) it should be easy to implement: you always unroll and substitute at compile time, because struct, class, and enum are guaranteed to be fixed size.

The above foreach would be equivalent to:

{
alias bar.a n;
my_print(n);
}
{
alias bar.b n;
my_print(n);
}

Kevin

Kevin Bealer wrote:

>How about iterating over structures:
>
>myprint(double x) {...}
>myprint(int x) {...}
>
>// could be a class .. or an enum!
>struct foo {
>int a;
>double b;
>};
>
>foo bar;
>
>// syntax may need adjustment
>foreach(alias n, bar) {
>my_print(n);
>}
>
>Also, (it seems like) it should be easy to implement: you always unroll and
>substitute at compile time, because struct, class, and enum are guaranteed to be
>fixed size.
>
>The above foreach would be equivalent to:
>
>{
>alias bar.a n;
>my_print(n);
>}
>{
>alias bar.b n;
>my_print(n);
>}
>
>Kevin
>
>
>  
>

This is called reflection.  Many are hoping it will be included in D in one form or the another.  I like this idea and have been thinking along the same lines.  It would fit well with my variable arguments proposal.

-- 
-Anderson: http://badmama.com.au/~anderson/

"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c7dd4m$26un$1@digitaldaemon.com...
>
> How about iterating over structures:
>
> myprint(double x) {...}
> myprint(int x) {...}
>
> // could be a class .. or an enum!
> struct foo {
> int a;
> double b;
> };
>
> foo bar;
>
> // syntax may need adjustment
> foreach(alias n, bar) {
> my_print(n);
> }

Sorry, I don't think that's a good idea. foreach is reserved for collections.

I can't see any benefit, c/w the increased complexity and difficulty in implementing and understanding the language.

In article <c7dlbq$2k5h$1@digitaldaemon.com>, Matthew says...
>
>
>"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c7dd4m$26un$1@digitaldaemon.com...
>>
>> How about iterating over structures:
>>
>> myprint(double x) {...}
>> myprint(int x) {...}
>>
>> // could be a class .. or an enum!
>> struct foo {
>> int a;
>> double b;
>> };
>>
>> foo bar;
>>
>> // syntax may need adjustment
>> foreach(alias n, bar) {
>> my_print(n);
>> }
>
>Sorry, I don't think that's a good idea. foreach is reserved for collections.

Yes.  A struct is a collection.

>I can't see any benefit, c/w the increased complexity and difficulty in implementing and understanding the language.

Serialization of objects depends on this feature; you can tell, because applications that have to serialize data streams do this by hand (or with code generation, like ASN.1, XML, IReader/IWriter (in the D sample code), etc.)

Most web, db, persistence, markup problems are solved with serialization.

We usually view it from the other angle: datatypes "store" the data so you can build the "real" object (the XML snippet or whatever).

Kevin

"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c7do9r$2ooj$1@digitaldaemon.com...
> In article <c7dlbq$2k5h$1@digitaldaemon.com>, Matthew says...
> >
> >
> >"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c7dd4m$26un$1@digitaldaemon.com...
> >>
> >> How about iterating over structures:
> >>
> >> myprint(double x) {...}
> >> myprint(int x) {...}
> >>
> >> // could be a class .. or an enum!
> >> struct foo {
> >> int a;
> >> double b;
> >> };
> >>
> >> foo bar;
> >>
> >> // syntax may need adjustment
> >> foreach(alias n, bar) {
> >> my_print(n);
> >> }
> >
> >Sorry, I don't think that's a good idea. foreach is reserved for collections.
>
> Yes.  A struct is a collection.

Well, so is an int, if you want to take it that far. Do you want to be able to freach an int for its bits?

> >I can't see any benefit, c/w the increased complexity and difficulty in implementing and understanding the language.
>
> Serialization of objects depends on this feature; you can tell, because applications that have to serialize data streams do this by hand (or with code generation, like ASN.1, XML, IReader/IWriter (in the D sample code), etc.)
>
> Most web, db, persistence, markup problems are solved with serialization.
>
> We usually view it from the other angle: datatypes "store" the data so you can build the "real" object (the XML snippet or whatever).

That's more like it.

In that case, I would argue for another construct, as the confusion object is still valid.

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c7dofo$2p2a$1@digitaldaemon.com...
>
> "Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c7do9r$2ooj$1@digitaldaemon.com...
> > In article <c7dlbq$2k5h$1@digitaldaemon.com>, Matthew says...
> > >
> > >
> > >"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c7dd4m$26un$1@digitaldaemon.com...
> > >>
> > >> How about iterating over structures:
> > >>
> > >> myprint(double x) {...}
> > >> myprint(int x) {...}
> > >>
> > >> // could be a class .. or an enum!
> > >> struct foo {
> > >> int a;
> > >> double b;
> > >> };
> > >>
> > >> foo bar;
> > >>
> > >> // syntax may need adjustment
> > >> foreach(alias n, bar) {
> > >> my_print(n);
> > >> }
> > >
> > >Sorry, I don't think that's a good idea. foreach is reserved for
collections.
> >
> > Yes.  A struct is a collection.
>
> Well, so is an int, if you want to take it that far. Do you want to be able to freach an int for its bits?
>
> > >I can't see any benefit, c/w the increased complexity and difficulty in implementing and understanding the language.
> >
> > Serialization of objects depends on this feature; you can tell, because applications that have to serialize data streams do this by hand (or with
code
> > generation, like ASN.1, XML, IReader/IWriter (in the D sample code), etc.)
> >
> > Most web, db, persistence, markup problems are solved with serialization.
> >
> > We usually view it from the other angle: datatypes "store" the data so you
can
> > build the "real" object (the XML snippet or whatever).
>
> That's more like it.
>
> In that case, I would argue for another construct, as the confusion object is still valid.

"objection" I meant

In article <c7dofo$2p2a$1@digitaldaemon.com>, Matthew says...
>
>
>"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c7do9r$2ooj$1@digitaldaemon.com...
>> In article <c7dlbq$2k5h$1@digitaldaemon.com>, Matthew says...
>> >
>> >
>> >"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c7dd4m$26un$1@digitaldaemon.com...
>> >>
>> >> How about iterating over structures:
>> >>
>> >> myprint(double x) {...}
>> >> myprint(int x) {...}
>> >>
>> >> // could be a class .. or an enum!
>> >> struct foo {
>> >> int a;
>> >> double b;
>> >> };
>> >>
>> >> foo bar;
>> >>
>> >> // syntax may need adjustment
>> >> foreach(alias n, bar) {
>> >> my_print(n);
>> >> }
>> >
>> >Sorry, I don't think that's a good idea. foreach is reserved for collections.
>>
>> Yes.  A struct is a collection.
>
>Well, so is an int, if you want to take it that far. Do you want to be able to freach an int for its bits?
>
>> >I can't see any benefit, c/w the increased complexity and difficulty in implementing and understanding the language.
>>
>> Serialization of objects depends on this feature; you can tell, because applications that have to serialize data streams do this by hand (or with code generation, like ASN.1, XML, IReader/IWriter (in the D sample code), etc.)
>>
>> Most web, db, persistence, markup problems are solved with serialization.
>>
>> We usually view it from the other angle: datatypes "store" the data so you can build the "real" object (the XML snippet or whatever).
>
>That's more like it.
>
>In that case, I would argue for another construct, as the confusion object is still valid.

Another syntax is fine with me.  Maybe:

struct my_quux {
int x;
double y;
}

char[] as_string(double v) {..}
char[] as_string(int v) {..}

for_parts(foo; bar; my_quux) {
// iteration 1: foo=type alias for int,    bar=object alias for x
// iteration 2: foo=type alias for double, bar=object alias for y

foo half = bar / 2;
printf("foo size %d half value %.s\n",
foo.sizeof, as_string(half));
}

Better? worse?

Kevin

>> Serialization of objects depends on this feature; you can tell, because applications that have to serialize data streams do this by hand (or with code generation, like ASN.1, XML, IReader/IWriter (in the D sample code), etc.)
>>
>> Most web, db, persistence, markup problems are solved with serialization.
>>
>> We usually view it from the other angle: datatypes "store" the data so you can build the "real" object (the XML snippet or whatever).
>
>That's more like it.
>
>In that case, I would argue for another construct, as the confusion object is still valid.

Since this would require a new construct for the compiler, would it be a huge stretch to go to full-on reflection instead of expanding 'foreach'?

IMO, I like the elegance in using foreach in the manner suggested, but a beefed-up type/reflection system could prove more useful outside of serialization.

// possible serialization with a bogus xmlWriter class.
foreach(type.field f; myObj.type.fields){
xmlWriter.BeginTag("field");
xmlWriter.AddAttribute("name",f.name.toString());
xmlWriter.AddAttribute("type",f.type.toString());
xmlWriter.AddAttribute("value",f.toString());
xmlWriter.EndTag();
}

// invoking a method by name
void CallMethod(object myObj){
myObj.type.method["name"].call();
}

// stronger debugging output??
catch(Exception e){
printf(e.toString() ~ "(caught in " ~ this.type.thismethod.name.toString() ~
")");
}

It's a neat way to do compile time reflection. I don't think it will serve for runtime reflection, though (i.e. getting an arbitrary Object and wondering what its members are without knowing the type).

Walter wrote:

>It's a neat way to do compile time reflection. I don't think it will serve
>for runtime reflection, though (i.e. getting an arbitrary Object and
>wondering what its members are without knowing the type).
>  
>
Parhaps objects should handle there own reflection.  If an object needs to expose it members at runtime you could use the static method to do so.

-- 
-Anderson: http://badmama.com.au/~anderson/