"Anders F Björklund" <afb@algonet.se> wrote in message news:d155s8$2md5$6@digitaldaemon.com...
> Kris wrote:
>
> >>And I did say that _ should be reserved, just wasn't sure if the D compiler was up to actively protecting them or not ?
> >
> > Nope. And doing so would not be backward compatible with C. This is why
the
> > '$' or '@' prefix was started. This is just going around in circles :-)
>
> I'm on the '_' side then. Even if it is not actively protected...

Excellent! That's a far better solution than changing things to be fully deterministic :-)


> >>Since it was C after all, you could still use them. And face the wrath.
> >
> > And D should not enforce the policy? I disagree.
>
> So it seems. And I don't think this discussion goes much longer.

Agreed :-)


> > And here's a nice & easy opportunity to simplify some questionable and inconsistent C syntax. Are you saying that the need for these specific things to be backward compatible with C is more important than overall simplicity and consistency of use? Because that's what Walter appears to
be
> > saying.
>
> Adding new things like $ and @ to identifiers is a rather big change ?


Oh. I don't think it would stump Walter. Do you? He's already talking about doing it for other things, and he's gonna' have to do something about [length]. This seems largely irrelevant?


> Maybe even better to take __FILE__ and __DATE__ back out again, then.

Yep ~ we should all stick our heads into the sand :-)

>
> >>Q: Would adding *both* work ? _file (newcomers) and __FILE__ (oldtimers)
> >
> > Why? It's far better to be consistent. Particularly so when the
opportunity
> > is just sitting there. If you wish to discuss the pros and cons of consistency, then let's take it out of this thread.
>
> Nah, I'm just trying to meddle so we can get on with our lives...
>
> Sorta like how adding the "bool" alias put a truce to *that* war.


That would be great, Anders. And I'm with you regarding the '_' prefix as long as the compiler makes it illegal elsewhere. If that doesn't happen, then another approach is needed. The solutions are not difficult. Instead, the whole thing appears to be encased in a tomb of petty politics.

On Mon, 14 Mar 2005 23:38:37 +0100, Anders F Björklund wrote:

> Derek Parnell wrote:
> 
>> I was actually thinking more like ...
>> 
>>   str = args[ args.length - 1  ..  args.length ];
>> 
>> or
>> 
>>   str = args[ $ - 1  ..  $ ];
>> 
>> in other words - whitespace is your friend :D
> 
> Ah, OK!
> Then I was going in the right direction after all... :-)
> 
> How does this (actual) code look to you then:
> m_keys = m_keys[0 .. i] ~ m_keys[i+1 .. m_keys.length];

Well, seeing you asked, I'd prefer ...

#  m_keys = m_keys[0 .. i] ~ m_keys[i + 1 .. $];

only because the '$' is faster to grok than "m_keys.length". The eye has to read the 13 characters and register it in the brain, in context, before it can click on what the coder is trying to say. The '$' makes the same point in a much faster manner.

I guess though, its whatever one becomes accustomed to reading.

> I was wonder whether I should do a "pop()" inline or not, but decided it was simple enough to leave as a one-liner ?

Actually, I'd go with a "pop()" because it is a more concise expression of the coder's intention. In other words, a reader of the code will more quickly understand what you are trying to say with "pop()" than reading and making sense of the longer statement.

I try to code for human readers rather than for compilers.

-- 
Derek
Melbourne, Australia
15/03/2005 10:30:08 AM

Derek Parnell wrote:

> Well, seeing you asked, I'd prefer ...
> 
> #  m_keys = m_keys[0 .. i] ~ m_keys[i + 1 .. $];
> 
> only because the '$' is faster to grok than "m_keys.length". The eye has to
> read the 13 characters and register it in the brain, in context, before it
> can click on what the coder is trying to say. The '$' makes the same point
> in a much faster manner.

Okay, I will consider it - once my GDC supports it :-)

> Actually, I'd go with a "pop()" because it is a more concise expression of
> the coder's intention. In other words, a reader of the code will more
> quickly understand what you are trying to say with "pop()" than reading and
> making sense of the longer statement.
> 
> I try to code for human readers rather than for compilers.

The code (i.e. the "pop" function) was only used twice.

--anders

Kris wrote:

> Excellent! That's a far better solution than changing things to be fully
> deterministic :-)

:-)
Just went back to the fallback: "I'm with Stupid" = let's do like C did.

> Oh. I don't think it would stump Walter. Do you? He's already talking about
> doing it for other things, and he's gonna' have to do something about
> [length]. This seems largely irrelevant?

Nope, I don't think it's too much. Just seemed overkill for this one ?

But maybe it needs to be withdrawn, and then redone properly instead ?

> That would be great, Anders. And I'm with you regarding the '_' prefix as
> long as the compiler makes it illegal elsewhere. If that doesn't happen,
> then another approach is needed. The solutions are not difficult. Instead,
> the whole thing appears to be encased in a tomb of petty politics.

Let's leave it at that then, and see what happens and what Walter says.

Meanwhile, there's a GDC to be updated and I posted a few other patches?
I'm sure there will be other things too, but this was my week's D budget
;-)

--anders

In article <d156p4$2qfl$1@digitaldaemon.com>, Kris says...
>
>That would be great, Anders. And I'm with you regarding the '_' prefix as long as the compiler makes it illegal elsewhere.

So what would the compiler do with interfaces to C libraries that have leading underscore symbols?


Sean

Right. This is partly why the other prefixes were suggested; so that they /can/ be enforced (at least, I thought so).

I don't think for one moment that Walter would agree to restrict the '_' prefix.


"Sean Kelly" <sean@f4.ca> wrote in message news:d157fv$2r80$1@digitaldaemon.com...
> In article <d156p4$2qfl$1@digitaldaemon.com>, Kris says...
> >
> >That would be great, Anders. And I'm with you regarding the '_' prefix as long as the compiler makes it illegal elsewhere.
>
> So what would the compiler do with interfaces to C libraries that have
leading
> underscore symbols?
>
>
> Sean
>
>

Yep ~ I saw your patches. I hope they survive intact :-)


"Anders F Björklund" <afb@algonet.se> wrote in message news:d157ad$2qft$2@digitaldaemon.com...
> Kris wrote:
>
> > Excellent! That's a far better solution than changing things to be fully deterministic :-)
>
> :-)
> Just went back to the fallback: "I'm with Stupid" = let's do like C did.
>
> > Oh. I don't think it would stump Walter. Do you? He's already talking
about
> > doing it for other things, and he's gonna' have to do something about [length]. This seems largely irrelevant?
>
> Nope, I don't think it's too much. Just seemed overkill for this one ?
>
> But maybe it needs to be withdrawn, and then redone properly instead ?
>
> > That would be great, Anders. And I'm with you regarding the '_' prefix
as
> > long as the compiler makes it illegal elsewhere. If that doesn't happen, then another approach is needed. The solutions are not difficult.
Instead,
> > the whole thing appears to be encased in a tomb of petty politics.
>
> Let's leave it at that then, and see what happens and what Walter says.
>
> Meanwhile, there's a GDC to be updated and I posted a few other patches? I'm sure there will be other things too, but this was my week's D budget ;-)
>
> --anders