On Fri, 01 Feb 2013 14:17:00 -0500, Zach the Mystic
<[email protected]> wrote:
On Friday, 1 February 2013 at 18:34:01 UTC, Steven Schveighoffer wrote:
I think you are wrong in how you assume a struct works, but not in your
attempt to implement properties. Struct is just not a key to this
formula.
I disagree. It is absolutely the fundamental key to this formula.
Well, we can disagree, but you still haven't explained why it's
fundamental. Other languages have implemented properties just fine
without having to specify that they are structs or aggregate types. Until
you come up with a compelling reason for structs, I'll stand by my
position.
Note that many (including myself) consider the overloading of static to
be a *detriment*.
I guess there's certainly a matter of taste involved here. Had you
suggested another keyword, or what had your preferred suggested syntax
looked like?
@property. It's already there, already used for properties.
@property foo {
int get(); // or opGet
void set(int val); // or opSet
opBinary(...) // etc.
}
I'm sorry we couldn't find common ground here. I can imagine two camps
developing, one with your ideas and one with mine. As far as a static
struct function, how could it get the pointer to its enclosing struct,
which it needs in order operate on the enclosing struct's data?
There is NO difference between a static struct function and a normal
module-level function, EXCEPT in the namespace. How could it get the
pointer to its enclosing struct? It can't. Because a struct TYPE doesn't
HAVE an enclosing struct. It could have an enclosing struct TYPE, but
that's it. In order to have an instance pointer, it needs to have an
instance, and you need to have a non-static struct function.
Now, you are proposing that we have these special structs (nested structs)
must be labeled static, but are not actually static (their methods require
a context pointer), who can never have any fields, and whose methods
accept a this pointer is not the pointer to the struct instance, but the
instance of the containing type (be it class or struct) they reside in.
To say this is "just another struct" is an extremely large stretch.
I don't want to come across as mean or condescending, but what you have
described could never be considered a struct. Period. If you insist that
struct is to be used, you will be bashing your head against a brick wall
forever here. Drop the idea that it must be a struct, and you may gain
some traction. I'm not saying this because it's my opinion, I'm saying
this to prevent you from wasting any more time.
I don't really want to waste any more of my time either, if struct is what
you insist on, then I will respectfully bow out of the conversation.
-Steve
