I'm not too sure about $, __FILE__ or __LINE__. There might be a better way.

http://www.digitalmars.com/d/changelog.html

Walter, could you shed more light on this:

<cite>
If a module statement name is used with a package prefix, as in:
         import foo.bar;
then bar is not in scope, one must use foo.bar.
</cite>

???

Is this mean that if

import std.string;

then one must use fully qualified
std.string.memcpy name?

Thanks in advance,

Andrew.









"Walter" <newshound@digitalmars.com> wrote in message news:d0irlm$o0s$1@digitaldaemon.com...
> I'm not too sure about $, __FILE__ or __LINE__. There might be a better way.
>
> http://www.digitalmars.com/d/changelog.html
>
>
> 

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d0is5v$ofv$1@digitaldaemon.com...
> Walter, could you shed more light on this:
>
> <cite>
> If a module statement name is used with a package prefix, as in:
>          import foo.bar;
> then bar is not in scope, one must use foo.bar.
> </cite>
>
> ???
>
> Is this mean that if
>
> import std.string;
>
> then one must use fully qualified
> std.string.memcpy name?

That's right, but it only applies to the code within std\string.d. The circumstance happens rarely that one would qualify a name within the module itself.

Warnings? Whoa!  Walter, I know you didn't like the idea of warnings, so thanks for at least giving it a try.  I'm sure we'll let you know what we think.

Let me preface myself by saying that I haven't been following the $ or __FILE__ discussion (we've got waaay too much going on on this NG nowadays) so I aplogize if I'm stepping on anyone's toes.

As for $, __FILE__, and __LINE__...
I think we (we of course meaning Walter) should make #<valid identifier> a meta-keyword...  Then we replace length with $length, __FILE__ with $file, ect... All other valid identifiers prefixed with $ should be illegal...  This way, when one wants to add features such as these, it will not break existing code, and will not necessitate additional keywords. Perhaps there are even more uses for these "meta-keywords" as well.

Thoughts?

John Demme

Walter wrote:
> I'm not too sure about $, __FILE__ or __LINE__. There might be a better way.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> 
> 

"Walter" <newshound@digitalmars.com> wrote in message news:d0isrh$p4t$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d0is5v$ofv$1@digitaldaemon.com...
>> Walter, could you shed more light on this:
>>
>> <cite>
>> If a module statement name is used with a package prefix, as in:
>>          import foo.bar;
>> then bar is not in scope, one must use foo.bar.
>> </cite>
>>
>> ???
>>
>> Is this mean that if
>>
>> import std.string;
>>
>> then one must use fully qualified
>> std.string.memcpy name?
>
> That's right, but it only applies to the code within std\string.d. The
> circumstance happens rarely that one would qualify a name within the
> module
> itself.

Not so. Yesterday I defined toString() for three enums in std.openrj, and then needed to qualify each and every use with std.openrj because they were inside the DatabaseException class. This is intensely irritating (though I do not claim it as significant for that reason).

On this point - i.e. the notion of generalised/attribute-based coding, shims, etc. - I think it's a serious mistake to have instance methods have the same name as the shims, i.e. X.toString(), toString(int). It reduces the scope for generalised programming markedly. I had started to do distinct shims in DTL, i.e. to_string(), and will likely pursue this, despite its probable confusion factor, as I don't see any alternative. Shims are way too powerful to give away ....

"Walter" <newshound@digitalmars.com> wrote in message news:d0irlm$o0s$1@digitaldaemon.com...
> I'm not too sure about $, __FILE__ or __LINE__. There might be a better way.
>
> http://www.digitalmars.com/d/changelog.html

He he. I'm now inclining towards a more general approach to context dependency, following the $length, $count, etc. mentioned (by ??forgotten??; sorry) the other day.

Simply put, $ would mean 'within the context of the innermost entity', so:


    int[]    a = . . .

    if( 0 != a.length &&
        a[$length - 1] == 10)
    {
           ...

Thus $ is not 'wasted' on array length, and neither $len nor $length (nor anything else) are defined as some special funky kinds of keywords. Rather, $X means that X is relative. Like a deeper/funkier with.

I'll leave it to faster/sharper minds to come up with all the wild ramifications of this ...


:-)

All other valid identifiers prefixed with $ should be
> illegal...  This way, when one wants to add features such as these, it will not break existing code, and will not necessitate additional keywords. Perhaps there are even more uses for these "meta-keywords" as well.

Totally agree.

More candidates on this:

_arguments    ->$arguments
_argptr -> $argptr

Andrew.




"John Demme" <me@teqdruid.com> wrote in message news:d0itb3$pid$1@digitaldaemon.com...
> Warnings? Whoa!  Walter, I know you didn't like the idea of warnings, so thanks for at least giving it a try.  I'm sure we'll let you know what we think.
>
> Let me preface myself by saying that I haven't been following the $ or __FILE__ discussion (we've got waaay too much going on on this NG nowadays) so I aplogize if I'm stepping on anyone's toes.
>
> As for $, __FILE__, and __LINE__...
> I think we (we of course meaning Walter) should make #<valid identifier> a
> meta-keyword...  Then we replace length with $length, __FILE__ with $file,
> ect... All other valid identifiers prefixed with $ should be illegal...
> This way, when one wants to add features such as these, it will not break
> existing code, and will not necessitate additional keywords. Perhaps there
> are even more uses for these "meta-keywords" as well.
>
> Thoughts?
>
> John Demme
>
> Walter wrote:
>> I'm not too sure about $, __FILE__ or __LINE__. There might be a better way.
>>
>> http://www.digitalmars.com/d/changelog.html
>>
>> 

Walter, beg my pardon but still unclear....

<cite>
If a module statement name is used with a package prefix, as in:
 	import foo.bar;
</cite>

Shall it be

If a module statement name is used with a package prefix, as in:
  module foo.bar;

instead?

Thanks,

Andrew.


"Walter" <newshound@digitalmars.com> wrote in message news:d0isrh$p4t$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d0is5v$ofv$1@digitaldaemon.com...
>> Walter, could you shed more light on this:
>>
>> <cite>
>> If a module statement name is used with a package prefix, as in:
>>          import foo.bar;
>> then bar is not in scope, one must use foo.bar.
>> </cite>
>>
>> ???
>>
>> Is this mean that if
>>
>> import std.string;
>>
>> then one must use fully qualified
>> std.string.memcpy name?
>
> That's right, but it only applies to the code within std\string.d. The
> circumstance happens rarely that one would qualify a name within the
> module
> itself.
>
> 

"John Demme" <me@teqdruid.com> wrote in message news:d0itb3$pid$1@digitaldaemon.com...
> Warnings? Whoa!  Walter, I know you didn't like the idea of warnings, so thanks for at least giving it a try.  I'm sure we'll let you know what we think.
>
> Let me preface myself by saying that I haven't been following the $ or __FILE__ discussion (we've got waaay too much going on on this NG nowadays) so I aplogize if I'm stepping on anyone's toes.
>
> As for $, __FILE__, and __LINE__...
> I think we (we of course meaning Walter) should make #<valid
> identifier> a meta-keyword...  Then we replace length with $length,
> __FILE__ with $file, ect... All other valid identifiers prefixed with
> $ should be illegal...  This way, when one wants to add features such
> as these, it will not break existing code, and will not necessitate
> additional keywords. Perhaps there are even more uses for these
> "meta-keywords" as well.
>
> Thoughts?

Don't like it.

First: $ as a prefix may be getting a far more important and central role in the language.

Second: __FILE__ and __LINE__ are damn ugly, and that's a good thing. Making them less so might incline people to over/ab-use

Third: __FILE__ and __LINE__ are standard parts of other languages, and widely recognised by most/all programmers.

Matthew wrote:
> "Walter" <newshound@digitalmars.com> wrote in message news:d0irlm$o0s$1@digitaldaemon.com...
> 
>>I'm not too sure about $, __FILE__ or __LINE__. There might be a better way.
>>
>>http://www.digitalmars.com/d/changelog.html
> 
> 
> He he. I'm now inclining towards a more general approach to context dependency, following the $length, $count, etc. mentioned (by ??forgotten??; sorry) the other day.
> 
> Simply put, $ would mean 'within the context of the innermost entity', so:

I don't think that's the best definition, as I think that that's the default. The way I read it, these are equivalent:
array[4..length];
and
array[4..$length];

It doesn't say anything about certain identifiers only existing after a $.

> 
> 
>     int[]    a = . . .
> 
>     if( 0 != a.length &&
>         a[$length - 1] == 10)
>     {
>            ...
> 
Looking at the example, it seems to me what you want is that $<identifier> is an alias for the property of the last variable in the chain.  Example:
a.b.c($something);
the $something returns c.something if it exists, then b.something if it exists, then a.something if it exists, or doesn't compile... or am I looking too far into this?

John Demme