On Friday, 1 February 2013 at 19:59:12 UTC, Steven Schveighoffer
wrote:
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.
Okay, fair.
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 totally sorry. I had meant that some time ago, static was not
used so widely in D, and I'll concede it's a bit bulky, for what
it does. I wondered what you wanted then that would look or feel
better than having "static" plastered all over the place.
Having said that, I admit your syntax for @property is pretty
good. I think it does the job. Now I have to demonstrate why
structs would do the job better.
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.
Okay, I can see the confusion... what need to become static are
all *current* nested structs. These new special structs are not
labelled static at all, precisely because of how important it is
for them to define functions which hold pointers to instances of
their parent type, no different at all from how it currently
works with structs nested in functions. It's a code breakage I'm
talking about here. And thank goodness it's one that's relatively
easily handled. All normal structs will now define functions
which accept a hidden pointer to their enclosing scope. There
will be a small performance penalty, just like when a struct
inside a function is not marked static, for programmers who fail
to mark their nested structs static when possible. My other posts
here and a comment by Era Scarecrow on the other thread are
starting to address how this transition might be mitigated:
http://forum.dlang.org/thread/[email protected]?page=13
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
Maybe we both need some time to think about what has already been
said.
