View mode: basic / threaded / horizontal-split · Log in · Help
March 08, 2005
DMD 0.116 release
I'm not too sure about $, __FILE__ or __LINE__. There might be a better way.

http://www.digitalmars.com/d/changelog.html
March 08, 2005
Re: DMD 0.116 release
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
>
>
>
March 08, 2005
Re: DMD 0.116 release
"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.
March 08, 2005
Re: DMD 0.116 release
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
> 
> 
>
March 08, 2005
Re: DMD 0.116 release
"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 ....
March 08, 2005
Re: DMD 0.116 release
"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 ...


:-)
March 08, 2005
Re: DMD 0.116 release
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
>>
>>
March 08, 2005
Re: DMD 0.116 release
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.
>
>
March 08, 2005
Re: DMD 0.116 release
"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.
March 08, 2005
Re: DMD 0.116 release
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
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home