March 08, 2005
"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d0iv6b$rp8$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:d0iuk9$r4j$1@digitaldaemon.com...
> >
> > "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d0itsj$q7v$1@digitaldaemon.com...
> >> Walter, beg my pardon but still unclear....
> >
> > ------------ old way, doesn't work anymore ------------------
> >
> > module foo.bar;
> >
> > void test() { }
> >
> > void func()
> > {
> >    bar.test();
> > }
> >
> > ------------- new way ------------------
> >
> > module foo.bar;
> >
> > void test() { }
> >
> > void func()
> > {
> >    foo.bar.test();
> > }
> >
> > ------------------------------------------
>
> That's at least a lot more sensible.

What happened was the old way was done before there were packages. I'd overlooked it until now.


> Tell me, the rusty old twit, can alias work to disambiguate same-named functions from multiple modules?

Why not just put the module name in front of it to disambiguate them? That's how it's supposed to work.


March 08, 2005
"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d0iur7$rf4$1@digitaldaemon.com...
> I see now. Thanks a lot, Walter, for comments.
>
> Could you change then
>
> import foo.bar;
> to
> module foo.bar;
>
> here http://www.digitalmars.com/d/changelog.html#new0116 ?

Right. oops!


March 08, 2005
In article <d0iuk9$r4j$1@digitaldaemon.com>, Walter says...
>
>
>"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d0itsj$q7v$1@digitaldaemon.com...
>> Walter, beg my pardon but still unclear....
>
>------------ old way, doesn't work anymore ------------------
>
>module foo.bar;
>
>void test() { }
>
>void func()
>{
>    bar.test();
>}
>
>------------- new way ------------------
>
>module foo.bar;
>
>void test() { }
>
>void func()
>{
>    foo.bar.test();
>}
>
>------------------------------------------


Thank you for the clarification, Walter.  I was scratching my head pretty hard from your description in the change log.

So I gather that we're supposed to use aliases to get the old behavior, if that's what we want?

- EricAnderton at yahoo
March 08, 2005
Warning messages with Mango:


#  char[] get (char[] name)
#  {
#      if (name in dictionary)
#          return dictionary[name];
#      return null;
#  }

the above produces a "statement not reachable" message for the null return. I think you'd agree that the statement most certainly should be reachable?


#  output (";Max-Age=") (Int.format (tmp, maxAge));

The warning "implicit conversion of type long to int can cause loss of data" caught a Mango v1.2 change when formatting a cookie-age ~ it should have stated Long.format(tmp, maxAge) instead. I borked that when updating from a generic xtoi() routine that accepted a long. Thank goodness for warnings!


# if (i >= 0)
#     return format (dst, i, Radix.Decimal);
#
# uint len = dst.length - format (dst[1..length], -i, Radix.Decimal).length;

Another bogus "statement is unreachable" message. Variable 'i' is an int, so it can be less than zero.


#  if (! len)
#        throw error;
#  if (fill != tChar.init)

Yet another. The unreachable-code warning seems to be broken?


#  try {
#       getSize();
#       return true;
#       } catch (IOException){}
#  return false;

And another.

I have to keep commenting-out code to get the compiler to move on, and I know this unreachable-code thing is gonna' produce a lot more messages (at this rate). Can you fix this please, and then I'll continue?

Thanks;


March 08, 2005
Kris wrote:
> Warning messages with Mango:
> 
> 
> #  char[] get (char[] name)
> #  {
> #      if (name in dictionary)
> #          return dictionary[name];
> #      return null;
> #  }
> 
> the above produces a "statement not reachable" message for the null return. I
> think you'd agree that the statement most certainly should be reachable?
> 

humm... i'm not 100% but i think the reason it is not reachable is because if the 'if statement' is true then the 'return null' will be the 'dead code'

simple fix would be...

if (name in dictionary)
   return dictionary[name];
else
   return null;

unless i'm just not understanding your point... :-/
March 08, 2005
> I suspect the latter won't compile, but I'm sure you get the point
Sure :)


March 08, 2005
"Kris" <Kris_member@pathlink.com> wrote in message news:d0j2gi$vfp$1@digitaldaemon.com...
> Warning messages with Mango:
>
>
> #  char[] get (char[] name)
> #  {
> #      if (name in dictionary)
> #          return dictionary[name];
> #      return null;
> #  }
>
> the above produces a "statement not reachable" message for the null
> return. I
> think you'd agree that the statement most certainly should be
> reachable?

Could be some hat-eating here ...

> #  output (";Max-Age=") (Int.format (tmp, maxAge));
>
> The warning "implicit conversion of type long to int can cause loss of
> data"
> caught a Mango v1.2 change when formatting a cookie-age ~ it should
> have stated
> Long.format(tmp, maxAge) instead. I borked that when updating from a
> generic
> xtoi() routine that accepted a long. Thank goodness for warnings!

:-)



March 08, 2005
"pragma" <pragma_member@pathlink.com> wrote in message news:d0ivr5$sh5$1@digitaldaemon.com...
> So I gather that we're supposed to use aliases to get the old behavior, if that's what we want?

Yes, you could use an alias.


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

Why not just make with() apply to arrays as well?

Cleaner, imo.

with(a) x[0..length] = a[0..length];

March 08, 2005
On Tue, 8 Mar 2005 14:07:25 +1100, Matthew wrote:

> "Kris" <Kris_member@pathlink.com> wrote in message news:d0j2gi$vfp$1@digitaldaemon.com...
>> Warning messages with Mango:
>>
>>
>> #  char[] get (char[] name)
>> #  {
>> #      if (name in dictionary)
>> #          return dictionary[name];
>> #      return null;
>> #  }
>>
>> the above produces a "statement not reachable" message for the null
>> return. I
>> think you'd agree that the statement most certainly should be
>> reachable?
> 
> Could be some hat-eating here ...

Maybe, but I'm starting to think that Walter's idea of unreachable code is a lot different than mine. I'm getting a lot of this type of thing ...

void search() {
    char[] [] lFiles;
    FileDateTime lCurFileTime;
    bool lCanUse;
    int lTextPos = 0;

    if(mHasBeenSearched) {
        return;
    }

    if(mVerboseMode) {   //<<<<<<<< UNREACHABLE? I don't think so!
      writefln("Scanning %s", mFileName);
    }

[snipped a whole mess of code]

        mHasBeenSearched = true;
}



>> #  output (";Max-Age=") (Int.format (tmp, maxAge));
>>
>> The warning "implicit conversion of type long to int can cause loss of
>> data"
>> caught a Mango v1.2 change when formatting a cookie-age ~ it should
>> have stated
>> Long.format(tmp, maxAge) instead. I borked that when updating from a
>> generic
>> xtoi() routine that accepted a long. Thank goodness for warnings!
> 
> :-)

This caught a mistake by me too. I had ...

   int x = atoi(text);

Silly me thinking that 'atoi' meant ASCII text to int. It actually returns a long!

Another time I had to change ...

    bool IsActive( char[] pID )
    {
      return ( (pID in vActiveVersions) != null);
    }

to this ...

    bool IsActive( char[] pID )
    {
    return (pID in vActiveVersions) !== null ? true : false ;
    }

which is actually better code.

-- 
Derek
Melbourne, Australia
8/03/2005 2:46:53 PM