Walter Bright wrote:

> For example, even accessing a global variable isn't straightforward, if you look under the hood.

Depending on the education under the hood is always a turing machine, Lisp, pseudo code, ...

-manfred

On Saturday, 26 January 2013 at 05:39:05 UTC, Walter Bright wrote:
> On 1/25/2013 2:14 PM, Jonathan M Davis wrote:
>> A property function is fundamentally different from a
>> normal function by its very nature, not just by its call syntax.
>
> I would have agreed with you on that for years, simply taking its veracity as an axiom, but lately I am not convinced at all of that assertion. I suspect the differences between a property, field, and method are purely contrivance.
>
> For example, even accessing a global variable isn't straightforward, if you look under the hood. If it's in a DLL or TLS, there may be a function call in there that is non-trivial.



Walter, that's not how TLS variables are generally implemented in C/C++.

They're *normal* variables, placed in a special section of the executable, which is automatically switched in and out on every context switch by the OS.

This is true on Windows, and I believe in Linux as well (http://stackoverflow.com/questions/2459692)

On 1/25/2013 10:06 PM, Mehrdad wrote:
> Walter, that's not how TLS variables are generally implemented in C/C++.

Since I implemented them, I know how they work.

> They're *normal* variables, placed in a special section of the executable, which
> is automatically switched in and out on every context switch by the OS.

This is not necessarily true at all. It isn't for OSX, for example, and there's nothing in the semantics of TLS which preclude calling a function.

On Saturday, 26 January 2013 at 07:25:24 UTC, Walter Bright wrote:
> On 1/25/2013 10:06 PM, Mehrdad wrote:
>> Walter, that's not how TLS variables are generally implemented in C/C++.
>
> Since I implemented them, I know how they work.

I wasn't being pedantic. That's why I said generally, not always.
Obviously you can implement things a million different ways...


>> They're *normal* variables, placed in a special section of the executable, which
>> is automatically switched in and out on every context switch by the OS.
>
> This is not necessarily true at all. It isn't for OSX, for example, and there's nothing in the semantics of TLS which preclude calling a function.


Again, I didn't say they're "necessarily" true either, hence why I mentioned Linux and Windows specifically.
OS X is really the odd one out here, not Windows or Linux.


But you missed my point, which was, yes, a lot of things COULD contain function calls. Even the two lines

	int i = 0;
	i++;

COULD contain a function call, but how is that in any shape or form relevant to the discussion about @property in any way?


Generally, it isn't a function call, and as far as the code is concerned, it isn't a function call.

The fact that you may have happened to implement something as a function call doesn't mean anything with regards to the difference between a function call and a direct access for the _programmer_.

26-Jan-2013 09:04, deadalnix пишет:
> On Friday, 25 January 2013 at 19:59:59 UTC, Andrei Alexandrescu wrote:
>> 1. Syntactic and semantic implications of properties that return
>> callable entities
>>
>
> I don't understand why this is a special case in the first place. It
> should behave just like a variable of the same type, period.
>
>> C has no methods so the syntax "object.method" does not apply to it.
>> In C++, "object.method" is probably the oddest construct in the entire
>> language: it returns a type that exists but has no name, is not
>> expressible syntactically, is not first class (one can't assign
>> "object.method" to a variable), and has only two allowed operations:
>> take address or apply the function call operator "()". Various C++
>> implementations have extensions that fix this.
>>
>> Both Walter and I consider these serious lapses in language design.
>> Two of the most accessible elements of syntax do things of
>> considerably low interest and use. I hope I now clarified why I have a
>> dim view of arguments that - implicitly or explicitly - assume the C
>> or C++ behavior in this area is an example to follow on technical
>> grounds. (Clearly, familiarity is a much better argument.)
>>
>
> Javascript or C# have solved that issue with C like language nicely.
> That is why I propose to do the same here (and considering how much C#
> has been mentioned here, it sound like a serious option). I know that
> Javascript is a poorly designed language, but on that very specific
> topic most people agree that was has been done at the time was pure genius.
>
> It removes the weird C/C++ object that have no expressible type, and
> simplify the situation. Additional benefice is that funName now behave
> the same in all situation, which is also a simplification of the situation.
>
>> 2. I have tried to add @property appropriately in Phobos, in
>> particular for ranges:
>>
>> struct SomeRange {
>>   @property bool empty();
>>   @property ref T front();
>>   void popFront();
>> }
>>
>> There's more "@property" to be seen with "save" and "back".
>> Subjectively that just didn't work well for me. It adds clutter to an
>> otherwise simple and straightforward API, and penalizes usage for
>> benefits that I could never reap. I understand how some people are
>> glad to put that in everywhere, and find meaning in requiring parens
>> with popFront and popBack but not the others. Yet for me it was
>> liberating (see 1 above too) I could just write "r.popFront" without
>> the parens and have it do its deed. It is the right semantics for a
>> simple syntax.
>>
>
> If you ask me, I think property have been abused in range design. Many
> ranges properties really shouldn't be properties.
>
> Additionally, this kind of boilerplate can easily be written by
> automated tools. Java or C# are very verbose, but it is very efficient
> to write program in them, as the tooling to a great job for you.
>

Automated tooling is admitting a defeat if we talk about expressive languages. Java was designed with automatic code manipulation in mind and even with todays proliferation of generators it's a pain to work with.

TL;DR code is written once and read many times.

-- 
Dmitry Olshansky

>> please give us your own code and preferred solution
>> to compile-time formatting string checking.
> I am not interested in formatting at all. I wrote about the general problem to incorporate expectable many DSL's into one big source base, as D is intended to serve large scale coding.

And what's the solution, for you? Using strings as DSL is somewhat common in D.

As for DSL, well, I have a parser generator project here
(https://github.com/PhilippeSigaud/Pegged), and I recently added the
capacity to add new rules to a grammar at runtime and modify the
resulting parse tree. I also used the existent, but unused macro
keyword in D to get source code that can define its own subsequent
grammar and parse tree transformations.
Oh, and grammars can call one another, so adding a new sublanguage to
a parent language is doable (I use this from time to time). I still
have weeks fo work on this to have it reach the level I want, but I
did not hit any wall up to now.
So adding clean-looking DSL can be done in D, I think.

> I am sure that your "stab at it" does not show any intent to approach the general problem.

No, indeed :) Since it's a recurring question here, I just showed it could be done. It's also a simple example of what can be done with D meta-programming capacities.

On Saturday, 26 January 2013 at 08:29:40 UTC, Dmitry Olshansky wrote:
> Automated tooling is admitting a defeat if we talk about expressive languages. Java was designed with automatic code manipulation in mind and even with todays proliferation of generators it's a pain to work with.
>
> TL;DR code is written once and read many times.

Using tooling is admitting defeat ? That is very misplaced pride (and not even an argument).

And if you think that verbose code is less readable, think twice, or follow both links :
http://code.jquery.com/jquery.js
http://code.jquery.com/jquery.min.js

No doubt the less verbose one is more readable !

On 1/25/2013 11:52 PM, Mehrdad wrote:
> The fact that you may have happened to implement something as a function call
> doesn't mean anything with regards to the difference between a function call and
> a direct access for the _programmer_.

I.e. the difference is purely a contrivance, which was my point.

On Saturday, 26 January 2013 at 09:04:47 UTC, Walter Bright wrote:
> On 1/25/2013 11:52 PM, Mehrdad wrote:
>> The fact that you may have happened to implement something as a function call
>> doesn't mean anything with regards to the difference between a function call and
>> a direct access for the _programmer_.
>
> I.e. the difference is purely a contrivance, which was my point.

Yes, that the whole point of abstraction. It happen that variables and functions are both very useful ones.

26-Jan-2013 12:57, deadalnix пишет:
> On Saturday, 26 January 2013 at 08:29:40 UTC, Dmitry Olshansky wrote:
>> Automated tooling is admitting a defeat if we talk about expressive
>> languages. Java was designed with automatic code manipulation in mind
>> and even with todays proliferation of generators it's a pain to work
>> with.
>>
>> TL;DR code is written once and read many times.
>
> Using tooling is admitting defeat ? That is very misplaced pride (and
> not even an argument).
>

There is no pride. Requiring a separate tool to generate code even in simple cases is a defeat. Using tools is fine to refactor, navigate etc. but not to generate "boilerplate" as in the end it still has to be read, modified and fitted with the rest of code. Boilerplate generally has no place in code at all if we can help it.

> And if you think that verbose code is less readable, think twice, or
> follow both links :
> http://code.jquery.com/jquery.js
> http://code.jquery.com/jquery.min.js
>
> No doubt the less verbose one is more readable !

Obfuscation/minification and boilerplate is not the same. And I bet the second example is the same exact code so you missed the point completely.

-- 
Dmitry Olshansky