Carlos Santander wrote:
> Walter Bright escribió:
>> Carlos Santander wrote:
>>> How can we check specific overloads with __traits? For example,
>>>
>>> class A
>>> {
>>>     abstract void foo();
>>>     int foo(int i) { return i; }
>>> }
>>>
>>> void main ()
>>> {
>>>     auto isvirtual = __traits(isAbstractFunction, A.foo); // what is it?
>>> }
>>
>> You'll need to split them apart with getVirtualFunctions, or cast the A.foo.
>>
> 
> As for getVirtualFunctions, I'm guessing abstract foo would not be virtual, and the other one would. Am I right?

Abstractness is orthogonal to virtualness - in this case, they're still virtual.

> 
> As for casting, cast A.foo to what?
> 

To the type signature of the particular overload you want.

Bill Baxter a écrit :
> James Dennett wrote:
>> BCS wrote:
>>> Reply to James,
>>>
>>>> Walter's version works on any platform where upper and lower case
>>>> letters have the same arrangement, including any gaps; yours is pretty
>>>> much tied to ASCII and extensions thereof.
>>>>
>>> good point, OTOH how often are non ASCII derived systems used (I've
>>> heard of a few but never run into any)
>>
>> With D, at present, probably none.  Some mainframes and
>> some embedded environments are the only remaining ones
>> I know about (though my knowledge is, of course, a long
>> long way from being encyclopedic.)
> 
> But both simple schemes for lowercasing will fail on things like accented characters.  Seeing tricks like that just to avoid calling tolower() makes me cringe.
> 
> --bb

True, it only work for real ASCII which has no accentuated characters.

renoX

On Tue, 24 Jul 2007 20:55:41 -0400, Robert Fraser wrote:

> for(int i = 100; i; i--) // Takes a second to mentally figure out what's going on

I'm still not explaining myself I guess. Yes, it doesn't take much to work out what the compiler is going to generate for that code. But that is not the issue I'm addressing.

If one see's a line of code like that one has trouble recognising that what was written may not have been what was intended to be written. How do we know that the code shouldn't have been ...

   for(int i = 100; i>1; i--)

and the coder made a small typo out of (bad?) habits. If however, one gets used to typing 'i>0' or similar fully specified comparisions, we all have a better confidence level that the code is written as intended to be written.

Of course, it is not a way to prevent all errors, but just a technique to reduce coding errors.

And a good compiler can still optimise such constructions without us having to hold its hand it all the way to the machine-code.

I write program code for humans not for computers. It's the compiler's job to prepare it for the computer.

Sorry that this sounds so pompous and self-righteous. That is not how I'm trying to sound.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

Robert Fraser wrote:
> 0ffh Wrote:
> "if(x != 0)" is just more explicit than "if(x)", but not many people use "if(b != false)" (unless you're that guy
> where I wrote who wrote "while(m_userSubscribed == Boolean.FALSE.booleanValue())", which I sincerely hope wasn't
> sincere), so being concise isn't bad as long as you're meaning is clear. I think it looks ugly in for loops, though: 

So help me glod I did not, but I consider that code line to be sarcastic humour! :)

> for(int i = 100; i; i--) // Takes a second to mentally figure out what's going on

Funny! I claim my brain parses the "i" /faster/ without the "=!0"!

"if (x)" takes me half a glance to parse and understand.
"if (x!=0)" takes at least three quarters of a glance.

Maybe it's just a matter of being used to use this construct?

Regards, Frank

Derek Parnell wrote:
> On Tue, 24 Jul 2007 20:55:41 -0400, Robert Fraser wrote:
> 
>> for(int i = 100; i; i--) // Takes a second to mentally figure out what's going on
> 
> I'm still not explaining myself I guess. Yes, it doesn't take much to work
> out what the compiler is going to generate for that code. But that is not
> the issue I'm addressing. 
> 
> If one see's a line of code like that one has trouble recognising that what
> was written may not have been what was intended to be written. How do we
> know that the code shouldn't have been ...
> 
>    for(int i = 100; i>1; i--) 

Well.. I'd say that is unlikely.

The more likely meaning was:
    for(int i = 100; i > 0; i--)

But! (to support your side of the argument here) the short form:
    for(int i = 100; i; i--)

actually means:
    for(int i = 100; i != 0; i--)

which is subtly different in the case where i is (mistakenly) set to a negative value inside the loop!

So, in this case I would have to agree that "i > 0" has a different meaning to plain "i" and prevents a bug as well.

In general, where the meaning is the same (i.e. "i == 0") I favour "if (i)" and have no trouble reading either form (which I think is a benefit we should all acquire you never know whose code you'll be reading next!)

Regan

Derek Parnell wrote:
> On Tue, 24 Jul 2007 20:55:41 -0400, Robert Fraser wrote:
> 
>> for(int i = 100; i; i--) // Takes a second to mentally figure out what's going on
> 
> I'm still not explaining myself I guess. Yes, it doesn't take much to work
> out what the compiler is going to generate for that code. But that is not
> the issue I'm addressing. 

I think maybe you wanted to address me here, not Robert.
A second is a looonng time! :)

> If however, one gets used to typing 'i>0' or similar fully specified comparisions,
> we all have a better confidence level that the code is written as intended to be written.
> Of course, it is not a way to prevent all errors, but just a technique to
> reduce coding errors.

I know the argument well. I use it myself to argue for fully braced
expressions instead of relying on operator precedence (apart from
the usual exceptions). Also, braces will actually help me parsing.

BUT there is a huge difference here: I'll repeat it this once before
stopping to do this (I don't believe in reiteration contests):

Using integers or pointers as bools is

  1. /Easy/ to understand and use correctly
  2. /Shorter/ - less to type and less to take in - and therefore
  3. /Faster/ to parse mentally (once you're used to it), also it's
  4. Not obligatory for those who feel uncomfortable with it, but
  5. Looks one darn hell better
     than having a detrimental tumour of nop characters attached.

> I write program code for humans not for computers. It's the compiler's job
> to prepare it for the computer.

Source code is for humans, machine code for computers, so far we agree.
But source code is for a /subclass/ of humans only: Those who are
knowledgeable in the programming language that was used. If I don't know
Miranda I will sure as heck not complain to Miranda programmers about their
unreadable code, because it is /my friggin fault/.
If I code in Miranda and I produce a bug because I do not understand the
mechanisms involved, it is still /my friggin fault/.

> Sorry that this sounds so pompous and self-righteous. That is not how I'm
> trying to sound.

Blast, don't kick yourself! I'll do that! :)

Regards, Frank The Eternally Distracted

Walter Bright wrote:
> The problem with explicit casts is that they are a brute force method, and subvert static type checking. A well designed systems allows a balance between implicit casting and strong type checking so that explicit casts are rarely needed in properly written programs.

I agree, but on a side note, shouldn't D's cast() operator be used exclusively to subvert *static* type checking?
(Since currently it's also used to check the runtime type of class, instead of a separate construct like Java's 'instanceof', C#'s 'is', or C++'s 'dynamic_cast')

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Georg Wrede wrote:
> 0ffh wrote:
>> James Dennett wrote:
>>
>>> BCS wrote:
>>>
>>>> [...]
>>>
>>> [...]
>>> (On the other hand, yours is idempotent, whereas Walter's
>>> depends on knowing that c started as upper case.)
>>
>>
>> Wow, idempotent!
>> I last read that word studying fuzzy logic! ;-)))
> 
> Yes, a fancy word, indeed.

Indeed.  It's a perfectly cromulent word. :)

> 
> OTOH, it's as important as "equivalence" and "implies".


-- 
- EricAnderton at yahoo

Walter Bright escribió:
> Carlos Santander wrote:
>> Walter Bright escribió:
>>> Carlos Santander wrote:
>>>> How can we check specific overloads with __traits? For example,
>>>>
>>>> class A
>>>> {
>>>>     abstract void foo();
>>>>     int foo(int i) { return i; }
>>>> }
>>>>
>>>> void main ()
>>>> {
>>>>     auto isvirtual = __traits(isAbstractFunction, A.foo); // what is it?
>>>> }
>>>
>>> You'll need to split them apart with getVirtualFunctions, or cast the A.foo.
>>>
>>
>> As for getVirtualFunctions, I'm guessing abstract foo would not be virtual, and the other one would. Am I right?
> 
> Abstractness is orthogonal to virtualness - in this case, they're still virtual.
> 

Lost me here. If both of them are still virtual, how could I "split them apart with getVirtualFunctions"?

>>
>> As for casting, cast A.foo to what?
>>
> 
> To the type signature of the particular overload you want.

__traits(isAbstractFunction, cast (int delegate (int) ) A.foo)    ?

-- 
Carlos Santander Bernal

Bruno Medeiros wrote:
> I agree, but on a side note, shouldn't D's cast() operator be used exclusively to subvert *static* type checking?
> (Since currently it's also used to check the runtime type of class, instead of a separate construct like Java's 'instanceof', C#'s 'is', or C++'s 'dynamic_cast')

I could argue it either way.