March 07, 2005
>> Plus the exception that gets thrown should be general enough to cover both cases. I  had to invent such an exception for MinTL but I'd really really love to just reuse a general "illegal index" exception from std.
>
>Well, that exception hierarchy refactoring effort's getting closer :-)

No problem. I'd be happy to get *an* exception and really happy to get a standard exception.

>> -Ben
>>
>> ps - Matthew, did you have too much coffee today? Your posts are ... intense.
>
>Well, I've had very little sleep in the last 48 hours, and I'm stupendously late in the preparation of the May instalment of my CUJ column - going to be about Open-RJ/D, which I've just sent (along with documentation!!!) to Walter - and I've released 7 libraries in the last two weeks, and I'm 3 weeks behind the most recent deadline for starting the writing of my next two books, and my last client's got *more* work for me.
>
>So, I guess I'm probably being more than a little strange.
>
>Sorry if it's getting old. Am off to grab some sleep now, so enjoy the cessation, and hope for a more sane barrage tomorrow. (Now that Open-RJ/D is done, I'll be busy on other things for a few days, so maybe the volume'll be down at least.)

No need to explain - it was just a surprise to be drinking my morning coffee and open up the newsgroup and see this barrage of posts. The more the better, though. A flame-war or two in morning is a good way to get the day started :-)

>
>Cheers
>
>Matthew


March 07, 2005
> Having multiple _disjoint_ meanings for a particular word doesn't trouble me. It's when those meanings can get confused that it's troubling.

It doesn't trouble me either! The point is that there doesn't seem to be a fixed position on these kind of issues.

Two 'in's that mean something completely different is okay with me. But what's up with all that talk about "$ instead of length because 'length' appears a lot in project x", "make x a keyword..." or "please don't make x a keyword" etc.

If it's okay to have two "in" commands (statements or whatever you call 'm), then it shouldn't be a problem to have any 'keywords' double in the language. We should be able to do "int int = 6;" because of the completely different meanings and positions of the two "int"s </extreme_example>. Yes, it'll be unreadable, but only because the programmer wants it to be.

I just like to generalize things. Or am I exaggerating again?

L.


March 07, 2005
"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:d0hbh4$250h$1@digitaldaemon.com...
> IMO, 3. is the only sane solution. It's the same problem with the stinky
crap of opCmp. Look at the rubbish I've had to
> write to get comparable Fields:


You only need opCmp(Object) if you are using builtin operations like .sort.
If you're going to use < or > operators with Fields, then opCmp(Field) is
all you need.


March 07, 2005
Walter wrote:

> You only need opCmp(Object) if you are using builtin operations like .sort.
> If you're going to use < or > operators with Fields, then opCmp(Field) is
> all you need.

I didn't think it was more than 4-5 lines extra code, either...

Then again, I was used to the Interface in question - from Java:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Comparable.html

--anders
March 07, 2005

Regan Heath wrote:
> but, now we're doing a double lookup.
> 
> So, to solve this, we return a pointer from 'in' (as we currently have)  OR...
> 
> we use a method call, eg.
> 
> array.contains("fred",value);
> 
> which returns true/false, and sets value if found.
> 
> I cannot see why you'd want anything else.

The method call is ok with me.

But, this should be separate, totally separate, from setting it!

We cannot afford to keep things like this. Period.

In a newcomers eye, this sticks out so bad, he'll think the rest of the language is the same. _We_ know it's not, but how do you convince them?

The syntax and words are a trivial matter, eg:

bool array.found("fred", value);
bool array.set("fred", value);
bool array.get("fred", value);

But since this (or some other naming) hasn't emerged yet, AT LEAST the newcomers (young, and seasoned alike) can't help but wondering about the internals being shaky. Heck, soon I'll be too.

And, nothing keeps us from using array.set("fed", value) to BOTH query and set at the same time. But the other two simply have to also exist.

March 07, 2005
I thought that one needed to manually override the method in any situation where the child class's method's parameter was a child of the parent's method's parameter... ie:
import std.stdio;

class C {
  void foo(C c) {
    writefln("C");
  }
}

class B: C {
  void foo(B b) {
    writefln("B");
  }
}

void main() {
        C b = new B();
        b.foo(b);
}

Prints "C", when I think it should print "B".  Is this something that D will do eventually, or no?

John

Walter wrote:
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message
> news:d0hbh4$250h$1@digitaldaemon.com...
> 
>>IMO, 3. is the only sane solution. It's the same problem with the stinky
> 
> crap of opCmp. Look at the rubbish I've had to
> 
>>write to get comparable Fields:
> 
> 
> 
> You only need opCmp(Object) if you are using builtin operations like .sort.
> If you're going to use < or > operators with Fields, then opCmp(Field) is
> all you need.
> 
> 
March 07, 2005
> Two 'in's that mean something completely different is okay with me. But what's up with all that talk about "$ instead of length because 'length' appears a lot in project x", "make x a keyword..." or "please don't make x
a
> keyword" etc.

I dislike this alot also.  I see three distinct uses of the 'in' keyword, if X 'in' collection , 'in' as a modifier for parameters, and 'in' as a contract specifier.

I like Matthew's suggestion, rename it contains or lookup

T value;
if (  AA.contains(x, T ) ) doSomething(T);


> But
> what's up with all that talk about "$ instead of length because 'length'

I dunno, this length non-sense is depressing ( length is bad enough but $ ? < shudders > ).  Why cant we all agree the Im smartest and that negative numbers look awesome as offests from the end! ;)

Charlie




"Lionello Lunesu" <lio@lunesu.removethis.com> wrote in message news:d0hvqf$2qgb$1@digitaldaemon.com...
> > Having multiple _disjoint_ meanings for a particular word doesn't
trouble
> > me. It's when those meanings can get confused that it's troubling.
>
> It doesn't trouble me either! The point is that there doesn't seem to be a fixed position on these kind of issues.
>
> Two 'in's that mean something completely different is okay with me. But what's up with all that talk about "$ instead of length because 'length' appears a lot in project x", "make x a keyword..." or "please don't make x
a
> keyword" etc.
>
> If it's okay to have two "in" commands (statements or whatever you call
'm),
> then it shouldn't be a problem to have any 'keywords' double in the language. We should be able to do "int int = 6;" because of the completely different meanings and positions of the two "int"s </extreme_example>.
Yes,
> it'll be unreadable, but only because the programmer wants it to be.
>
> I just like to generalize things. Or am I exaggerating again?
>
> L.
>
>


March 07, 2005
Are you really overriding the method in your example?

In main() you call foo() from an object of type C with a type C.  Does the method name as well as type need to be the same for an override? I'm not sure about this, because you new'd with a B(), and B inherits or implements C.  You can tell I've been writing way too much Java recently and not enough D.

I probably would have expected this to print "C".

BA

John Demme wrote:
> I thought that one needed to manually override the method in any situation where the child class's method's parameter was a child of the parent's method's parameter... ie:
> import std.stdio;
> 
> class C {
>   void foo(C c) {
>     writefln("C");
>   }
> }
> 
> class B: C {
>   void foo(B b) {
>     writefln("B");
>   }
> }
> 
> void main() {
>         C b = new B();
>         b.foo(b);
> }
> 
> Prints "C", when I think it should print "B".  Is this something that D will do eventually, or no?
> 
> John
> 
> Walter wrote:
> 
>> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message
>> news:d0hbh4$250h$1@digitaldaemon.com...
>>
>>> IMO, 3. is the only sane solution. It's the same problem with the stinky
>>
>>
>> crap of opCmp. Look at the rubbish I've had to
>>
>>> write to get comparable Fields:
>>
>>
>>
>>
>> You only need opCmp(Object) if you are using builtin operations like .sort.
>> If you're going to use < or > operators with Fields, then opCmp(Field) is
>> all you need.
>>
>>
March 07, 2005
"John Demme" <me@teqdruid.com> wrote in message news:d0i1rd$2t1f$1@digitaldaemon.com...
> Prints "C", when I think it should print "B".  Is this something that D will do eventually, or no?

What you're asking for is Java style overloading. D does C++ style overloading. There's been heated debate about which is better.


March 07, 2005
"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:422C8705.3010000@nospam.org...
> We cannot afford to keep things like this. Period.
>
> In a newcomers eye, this sticks out so bad, he'll think the rest of the language is the same. _We_ know it's not, but how do you convince them?

Javascript does it just that way, too.