June 10, 2003
"Walter" <walter@digitalmars.com> wrote in news:bc0d2j$20r6$1 @digitaldaemon.com:

> Many minor bugs fixed.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> 
Windows version Beta v0.65

The following should print:
count = 10

instead it prints:
count = 0


class Foo
{
  void Func(bit delegate() call)
  {
    for(int i = 0; i < 10; ++i)
      call();
  }
}

class Bar
{
	void Func()
	{
		int count = 0;

		Foo ic = new Foo();

		ic.Func(delegate bit() { ++count; return false; } );

		printf("count = %d\n",count);
	}
}

int main(char[][] argv)
{
	Bar b = new Bar();

	b.Func();

	return 0;
}
June 10, 2003
"Walter" <walter@digitalmars.com> wrote in news:bc0d2j$20r6$1 @digitaldaemon.com:

> Many minor bugs fixed.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> 

Walter the Windows version in the latest zip file has
version number 0.65 did it get updated to 0.66?
It was downloaded from  ftp://ftp.digitalmars.com/dmd.zip
June 10, 2003
"Patrick Down" <pat@codemoon.com> wrote in message news:Xns9395D338E3F2Epatcodemooncom@63.105.9.61...
> Walter the Windows version in the latest zip file has
> version number 0.65 did it get updated to 0.66?
> It was downloaded from  ftp://ftp.digitalmars.com/dmd.zip

Yeah, I know. <g>. It's still 0.66, though.


June 10, 2003
The following source prints out "default" on dmd linux 0.66:

int main(char[][] args)
{
  switch("asdf")
  {
  case "asdf":
    printf("asdf\n");
    break;


  case "jkl":
    printf("jkl\n");
    break;


  default:
    printf("default\n");
  }


  return 0;
}

If I change the switch to switch on args[1], then the switch works as it should.

June 11, 2003
I have this:

-----a.d
class A {}
-----b.d
private import a;
class B:A {}
-----c.d
import b;
B x; //works
A y; //doesn't work. great!
b.a.A z; //works

My question is if the last line should work. I'm not saying it shouldn't, I just want to know.

————————————————————————— Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.488 / Virus Database: 287 - Release Date: 2003-06-05


June 11, 2003
"Carlos Santander B." <carlos8294@msn.com> wrote in message news:bc61cl$vr7$1@digitaldaemon.com...
> I have this:
>
> -----a.d
> class A {}
> -----b.d
> private import a;
> class B:A {}
> -----c.d
> import b;
> B x; //works
> A y; //doesn't work. great!
> b.a.A z; //works
>
> My question is if the last line should work. I'm not saying it shouldn't,
I
> just want to know.

I know about that case, and have mixed feelings about whether it should work that way or be a bug.


June 11, 2003
Walter wrote:
> "Carlos Santander B." <carlos8294@msn.com> wrote in message
> news:bc61cl$vr7$1@digitaldaemon.com...
> 
>>I have this:
>>
>>-----a.d
>>class A {}
>>-----b.d
>>private import a;
>>class B:A {}
>>-----c.d
>>import b;
>>B x; //works
>>A y; //doesn't work. great!
>>b.a.A z; //works
>>
>>My question is if the last line should work. I'm not saying it shouldn't,
> 
> I
> 
>>just want to know.
> 
> 
> I know about that case, and have mixed feelings about whether it should work
> that way or be a bug.
> 

Since b is its own namespace, I can't see how that could ever cause a problem.  In fact, it looks like a useful construct, since it forces the fully qualified name to be used.

It is kind of misleading, though, seeing as how private tends to indicate that nobody outside the module should be able to see it.

Perhaps a protected import, or something of the like, is in order.

June 11, 2003
In article <bc7b28$24th$1@digitaldaemon.com>, Andy Friesen says...
>
>Walter wrote:
>> "Carlos Santander B." <carlos8294@msn.com> wrote in message news:bc61cl$vr7$1@digitaldaemon.com...
>> 
>>>I have this:
>>>
>>>-----a.d
>>>class A {}
>>>-----b.d
>>>private import a;
>>>class B:A {}
>>>-----c.d
>>>import b;
>>>B x; //works
>>>A y; //doesn't work. great!
>>>b.a.A z; //works
>>>
>>>My question is if the last line should work. I'm not saying it shouldn't,
>> 
>> I
>> 
>>>just want to know.
>> 
>> 
>> I know about that case, and have mixed feelings about whether it should work that way or be a bug.
>> 
>
>Since b is its own namespace, I can't see how that could ever cause a problem.  In fact, it looks like a useful construct, since it forces the fully qualified name to be used.
>
>It is kind of misleading, though, seeing as how private tends to indicate that nobody outside the module should be able to see it.
>
>Perhaps a protected import, or something of the like, is in order.
>

I think it definitely should not work. One way to think
about it is: If b does a PRIVATE import, then the
understood meaning is that b does not want the
whole world to gain access to all of a.

To let b.a.A work here would need a SERIOUS argument for it. We're developing a Straightforward language without undue catches and complications.



1 2
Next ›   Last »