View mode: basic / threaded / horizontal-split · Log in · Help
March 07, 2005
Re: in stinks
>> 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
Re: in stinks
> 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
Re: in stinks
"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
Re: in stinks (opCmp)
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
Re: in stinks
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
Re: in stinks
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
Re: in stinks
> 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
Re: in stinks
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
Re: in stinks
"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
Re: in stinks
"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.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home