Re: DIP 1003: remove `body` as a keyword
On Sat, Dec 10, 2016 at 4:43 PM, Basile B. via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Saturday, 10 December 2016 at 13:49:09 UTC, Basile B. wrote:
>
>> On Monday, 28 November 2016 at 02:17:20 UTC, Dicebot wrote:
>>
>>> On 11/24/2016 05:29 PM, WM.H wrote:
>>>
On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:
> DIP 1003 is merged to the queue and open for public informal feedback.
>
> PR: https://github.com/dlang/DIPs/pull/48
> Initial merged document:
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
>
> If you want the change to be approved and have ideas how to improve it
> to better match on https://github.com/dlang/DIPs/
> blob/master/GUIDELINES.md and existing published reviews - please
> submit new PR with editorial and ping original author.
>
This DIP fixes the problem for "body" but not for the other keywords.
After all the problem may exist for other keywords. Was a new pragma
considered ? For example an identifier alias.
pragma(idAlias, "body", "body_" )
>>>
>>> AFAIU, the point of this DIP is that "body" is standing out from other
>>> keywords being used only in one very specific context and being a very
>>> common english word at the same time. Your proposal has a completely
>>> different (and much more drastic) approach.
>>>
>>
>> Yes. But while it's clear that "body" is a keyword that's less related to
>> programming languages than the others (i.e more usable as identifier), it's
>> not actually that mad to imagine a generic approach. For example Object
>> Pascal has such a feature:
>>
>> http://wiki.freepascal.org/FPC_New_Features_2.6.0#Support_
>> for_.26-escaping_of_keywords
>>
>> which is not well known, as I've myself discovered this just 3 minutes
>> ago.
>> In D there would be the "#" token that's not really used, which could
>> serve to escape keywords, while still considering them as identifier when
>> it's needed, e.g
>>
>> struct Body{}
>> Body #body;
>> writeln("'", #body.stringof, "'");
>>
>> would output: 'body'
>>
>
> By the way a pragma was a bad idea. Pragmas are optionally supported by a
> compiler. An escape symbol is by far better. Whatever is the compiler we
> always want the same result.
>
> Any chance to get "Cauterite" thoughts on the option that is to have a
> token used to escape a keyword, so that the kw can be used as identifier ?
>
> The initial DIP is too specialized, however it shows a real problem:
>
> What if one day someone wants
>
> enum FlagsModifiedByAsmCmp {of, if, zf, cf} ?
> function Function;
>
> With an escape it would always work
>
> enum FlagsModifiedByAsmCmp {of, #if, zf, cf}
> #function Function;
>
> The problem of the suffix "_", as proposed in D style guide, is that it's
> also a valid identifier character, while "#" is not. And the best is that #
> role is already for special token sequences !
> - # = token for special token sequence
> - body = token
> => #body is a special token sequence.
>
> The only thing to change is that currently a special token sequence takes
> a full line...but seriously that's a minor change (since there's no special
> token sequence in D... #line is obsolete and not used anymore).
>
Why is #line obsolete? I use it a lot in string mixins to make the correct
line numbers show.
Thanks!
Re: Getters/setters generator
On Sunday, 11 December 2016 at 03:15:55 UTC, Mike Bierlee wrote: I was under the impression that you could only access methods as if they were fields using the @property attribute. After carefully reading the documentation I see this is not the case (UFCS does this). Still there are some added benefits from using @property to completely threat them as fields. It would be nice if you could add @property to the generated getters/setters. Right, any no-arg function can be called without parentheses, and single-arg functions can be called as 'func = foo'. At this point, I don't think think @property is ever going to be fixed to work as originally intended (and digging through the newsgroups will turn up several discussions on why, if you're interested). I don't bother with it anymore myself. DUB used to compile with it enabled by default, but no longer.
Re: Getters/setters generator
On Sunday, 11 December 2016 at 02:17:18 UTC, Mike Parker wrote: On Saturday, 10 December 2016 at 20:25:05 UTC, Mike Bierlee wrote: On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote: It would generate 2 methods "num": one to set num_ and one to get its value. It would be great if you could generate @properties instead. I like the more natural way of accessing those instead of getters/setters. What are properties if not "getters" and "setters"? From the original post: "It would generate 2 methods "num": one to set num_ and one to get its value." Two methods named "num". No "get" or "set" in sight. I was under the impression that you could only access methods as if they were fields using the @property attribute. After carefully reading the documentation I see this is not the case (UFCS does this). Still there are some added benefits from using @property to completely threat them as fields. It would be nice if you could add @property to the generated getters/setters.
Re: Getters/setters generator
On Saturday, 10 December 2016 at 20:25:05 UTC, Mike Bierlee wrote: On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote: It would generate 2 methods "num": one to set num_ and one to get its value. It would be great if you could generate @properties instead. I like the more natural way of accessing those instead of getters/setters. What are properties if not "getters" and "setters"? From the original post: "It would generate 2 methods "num": one to set num_ and one to get its value." Two methods named "num". No "get" or "set" in sight.
Re: Getters/setters generator
On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote: It would generate 2 methods "num": one to set num_ and one to get its value. It would be great if you could generate @properties instead. I like the more natural way of accessing those instead of getters/setters.
Re: Tutorial: Form upload in vibe.d
On Thursday, 8 December 2016 at 20:48:52 UTC, NVolcz wrote:
On Tuesday, 6 December 2016 at 22:28:04 UTC, aberba wrote:
[...]
Love the article! Please keep writing tutorials like this :-D.
Feedback:
1.
The upload function is (kind of) vulnerable against path
traversal:
moveFile(file.tempPath, Path("./public/uploads") ~
file.filename);
[...]
Thanks for feedback. Will consider those points raised in
thought. Will add more advanced stuff and security as time goes
on.
Re: Getters/setters generator
On Friday, 9 December 2016 at 16:30:55 UTC, Eugene Wissner wrote: On Friday, 9 December 2016 at 12:37:58 UTC, Iakh wrote: Is there possibility to remove affixes in generated accessor names? No, there is no way to manipulate the accessor names. What affixes do you mean? You can remove suffix "_" so "name_" becomes "name". But I like to see genarated accessors "name" for field "m_name"
Re: DConf 2017: Bigger, Badder, and Berliner! Call for Submissions now open
On 12/10/16 10:56 AM, Andrei Alexandrescu wrote: On 11/25/16 9:10 PM, Andy Smith wrote: I see this was pulled but no feedback as to whether it looked okay? Doesn't seem to have made its way into the Dconf 2017 site. Seriously I have no idea how my PR looks as I've not idea how to run ddoc. All I know is that the 2017 site as it stands could use a bit of love and I'm happy to help. Let me know :-) Cheers, A. Thanks, Andy. Everyone - somebody really needs to take over dconf.org, if I don't delegate some stuff I have so many jobs and my schedule is so fragmented, I can't really appear to make progress on anything. Forgot to mention - just uploaded the new logo, http://dconf.org/2017/index.html. Take a look! -- Andrei
Re: DConf 2017: Bigger, Badder, and Berliner! Call for Submissions now open
On 11/25/16 9:10 PM, Andy Smith wrote: I see this was pulled but no feedback as to whether it looked okay? Doesn't seem to have made its way into the Dconf 2017 site. Seriously I have no idea how my PR looks as I've not idea how to run ddoc. All I know is that the 2017 site as it stands could use a bit of love and I'm happy to help. Let me know :-) Cheers, A. Thanks, Andy. Everyone - somebody really needs to take over dconf.org, if I don't delegate some stuff I have so many jobs and my schedule is so fragmented, I can't really appear to make progress on anything. Andrei
Re: DIP 1003: remove `body` as a keyword
On Saturday, 10 December 2016 at 13:49:09 UTC, Basile B. wrote:
On Monday, 28 November 2016 at 02:17:20 UTC, Dicebot wrote:
On 11/24/2016 05:29 PM, WM.H wrote:
On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:
DIP 1003 is merged to the queue and open for public informal
feedback.
PR: https://github.com/dlang/DIPs/pull/48
Initial merged document:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
If you want the change to be approved and have ideas how to
improve it to better match on
https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and
existing published reviews - please submit new PR with
editorial and ping original author.
This DIP fixes the problem for "body" but not for the other
keywords. After all the problem may exist for other keywords.
Was a new pragma considered ? For example an identifier alias.
pragma(idAlias, "body", "body_" )
AFAIU, the point of this DIP is that "body" is standing out
from other keywords being used only in one very specific
context and being a very common english word at the same time.
Your proposal has a completely different (and much more
drastic) approach.
Yes. But while it's clear that "body" is a keyword that's less
related to programming languages than the others (i.e more
usable as identifier), it's not actually that mad to imagine a
generic approach. For example Object Pascal has such a feature:
http://wiki.freepascal.org/FPC_New_Features_2.6.0#Support_for_.26-escaping_of_keywords
which is not well known, as I've myself discovered this just 3
minutes ago.
In D there would be the "#" token that's not really used, which
could serve to escape keywords, while still considering them as
identifier when it's needed, e.g
struct Body{}
Body #body;
writeln("'", #body.stringof, "'");
would output: 'body'
By the way a pragma was a bad idea. Pragmas are optionally
supported by a compiler. An escape symbol is by far better.
Whatever is the compiler we always want the same result.
Any chance to get "Cauterite" thoughts on the option that is to
have a token used to escape a keyword, so that the kw can be used
as identifier ?
The initial DIP is too specialized, however it shows a real
problem:
What if one day someone wants
enum FlagsModifiedByAsmCmp {of, if, zf, cf} ?
function Function;
With an escape it would always work
enum FlagsModifiedByAsmCmp {of, #if, zf, cf}
#function Function;
The problem of the suffix "_", as proposed in D style guide, is
that it's also a valid identifier character, while "#" is not.
And the best is that # role is already for special token
sequences !
- # = token for special token sequence
- body = token
=> #body is a special token sequence.
The only thing to change is that currently a special token
sequence takes a full line...but seriously that's a minor change
(since there's no special token sequence in D... #line is
obsolete and not used anymore).
Re: DIP 1003: remove `body` as a keyword
On Monday, 28 November 2016 at 02:17:20 UTC, Dicebot wrote:
On 11/24/2016 05:29 PM, WM.H wrote:
On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:
DIP 1003 is merged to the queue and open for public informal
feedback.
PR: https://github.com/dlang/DIPs/pull/48
Initial merged document:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
If you want the change to be approved and have ideas how to
improve it to better match on
https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and
existing published reviews - please submit new PR with
editorial and ping original author.
This DIP fixes the problem for "body" but not for the other
keywords. After all the problem may exist for other keywords.
Was a new pragma considered ? For example an identifier alias.
pragma(idAlias, "body", "body_" )
AFAIU, the point of this DIP is that "body" is standing out
from other keywords being used only in one very specific
context and being a very common english word at the same time.
Your proposal has a completely different (and much more
drastic) approach.
Yes. But while it's clear that "body" is a keyword that's less
related to programming languages than the others (i.e more usable
as identifier), it's not actually that mad to imagine a generic
approach. For example Object Pascal has such a feature:
http://wiki.freepascal.org/FPC_New_Features_2.6.0#Support_for_.26-escaping_of_keywords
which is not well known, as I've myself discovered this just 3
minutes ago.
In D there would be the "#" token that's not really used, which
could serve to escape keywords, while still considering them as
identifier when it's needed, e.g
struct Body{}
Body #body;
writeln("'", #body.stringof, "'");
would output: 'body'
