"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D8201C9.B75E78DD@deming-os.org...
> Walter wrote:
> > I don't understand what the value of it is.
> The "element1" and "valid.element1" values are tied to each other.  I
don't
> really want to clutter up the namespace with similar names.  It's
particularly
> problematic in my circumstance because the D code we're referring to is automatically generated from user definitions..so what if he defined both
an
> "element1" and "xelement1" value for his purposes?  Then the user's "xelement1" conflicts with the automatically generated "xelement1", which
is
> just a property of the user's "element1".

Ok, I see. The way to do it is to create a unique prefix for your generated names, like _Foo_. Disallow the user from using _ in the names he types in, or disallow leading _.

I forgot to mention. You can also do things like:

struct Foo
{
    struct Bar { int x; }
    Bar b;
    int x;
}

and refer to b.x.

Walter wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D8201C9.B75E78DD@deming-os.org...
> > Walter wrote:
> > > I don't understand what the value of it is.
> > The "element1" and "valid.element1" values are tied to each other.  I
> don't
> > really want to clutter up the namespace with similar names.  It's
> particularly
> > problematic in my circumstance because the D code we're referring to is automatically generated from user definitions..so what if he defined both
> an
> > "element1" and "xelement1" value for his purposes?  Then the user's "xelement1" conflicts with the automatically generated "xelement1", which
> is
> > just a property of the user's "element1".
>
> Ok, I see. The way to do it is to create a unique prefix for your generated names, like _Foo_. Disallow the user from using _ in the names he types in, or disallow leading _.

Yeah, I do it like that for some other things, but don't really like it :(


--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Walter wrote:

> I forgot to mention. You can also do things like:
>
> struct Foo
> {
>     struct Bar { int x; }
>     Bar b;
>     int x;
> }
>
> and refer to b.x.

Right, that's what I do now, but it's ugly.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Walter" <walter@digitalmars.com> wrote in message news:alt3lr$235r$1@digitaldaemon.com...
> I forgot to mention. You can also do things like:
>
> struct Foo
> {
>     struct Bar { int x; }
>     Bar b;
>     int x;
> }
>
> and refer to b.x.

In C++ you can do:

struct Foo
{
    struct Bar { int x; }b;
    int x;
};

(Walter: That's what I refered to as "named type", as compared to declaring an *anonymous* struct type inside an other struct.)

and in C++ you can also do:


struct Foo
{
    struct { int x; }b;
    int x;
};

I still don't understand the reason for disallowing these constructs. What's the problem with them? Too complex for humans?

Sandor

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:als29h$nng$1@digitaldaemon.com...
> Now that sounds cool.

Indeed.

> Decorating member variables with little extra functions.  It's be nice to
be
> able to decorate types that way too.  Especially other classes.

Well we already have properties for classes. The invention here is that they behave as having a value of a different (actually built-in) type. And that is *cast overloading*. If you have cast overloading, then - for example - you can declare a class whose instances can be directly assigned to and from integers, and still have your new properties, or boolean fields, or whatever.

You can already do this in C++.



> "Russell Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D80CF9E.5070201@deming-os.org...
> > Sure, I know that's possible.  But that's no better than just defining the x elements in the main struct.  I would really prefer to access the elements as "valid.element1".  (Actually, I'd like to make "valid" a boolean property of both the element1 and element2 variable...but perhaps that's asking too much.
> >
> > Then again, you could conceivably use this sort of syntax:
> >
> > struct foo {
> >      bar element1
> >        properties {
> >          bool valid;
> >        };
> >      bar element2
> >        properties {
> >          bool valid;
> >        };
> > }
> >
> > The compiler would have to store the properties in the struct, but they would be accessible using the property syntax;
> >
> >      foo.element1  // refers to the variable, of type "bar"
> >      foo.element1.valid // referes to the property

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:am46cp$1gjs$1@digitaldaemon.com...
> I still don't understand the reason for disallowing these constructs.
What's
> the problem with them? Too complex for humans?

The reason is to simplify the parsing.
    struct B { members }
is not a type specifier in D.