Possible @property compromise

Zach the Mystic reachBUTMINUSTHISzach at gOOGLYmail.com
Fri Feb 1 13:44:38 PST 2013


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 
> <reachBUTMINUSTHISzach at googlymail.com> 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/kdukid$stg$1@digitalmars.com?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.


More information about the Digitalmars-d mailing list