"Lionello Lunesu" <lio@lunesu.remove.com> wrote in message news:e5pcja$td0$1@digitaldaemon.com...

> Please remove ?:...

I'll agree with you to an extent, though keep in mind that I am of the opinion that the tradeoff of a bit more space for a lot more readability is a Good Thing (TM).  ?: can be abused, certainly, but so can most of the other language constructs.  That code that you show is certainly abuse; any code where the effect isn't immediately obvious is, in my opinion, badly-written.  I've seen conditional statements nested three deep before. It's not a pretty thing.

I rarely use ?:, and when I do, it's always something very short and obvious, such as

char[] name = (numApples > 1) ? "apples" : "apple";

However, there will always be programmers who _like_ to nest conditional statements three deep, and because D is a practical language and not an ideological language, ?: won't be going away.

> What makes me wonder is why ?: looks faster. Does * look faster than /,
> then?
> Yet, it is on modern PCs. In my humble opinion, a programmer should not,
> generally speaking, judge expressions' performance by how many words or
> keywords
> are used.

When I'm writing libraries, I tend to give longer, complicated names to functions that are slow. People using libraries don't know the performance of a function, and with all that intellisense stuff, they don't read the docs. If you have an array and want to check whether it contains item X, they select "Contains(X)" from the intellisense popup and that's that. I had to rename the function to get it through to them that you don't want to be calling Contains(X) (doing a linear search) in an inner loop :S

Similarly, I think ?: looks faster than if...else but it's exactly the same construct (ok, ?: can also be an rvalue), resulting in the same code. * and / both result in 1 cpu instruction; 1 token -> 1 instruction seems perfect : )

L.

"pragma" <pragma_member@pathlink.com> wrote in message news:e5pr7d$1jmt$1@digitaldaemon.com...
> Being more direct and to the point leads to more readable and thus
> maintainable
> code.  Its really a good thing to have, provided its used responsibly (as
> with
> all of D's language constructs).

It's true that if you want to write unreadable code, you can do so no matter what, and there's little the grammar can do to prevent that.

>> D should be RISC :)
>
> In principle, this is a grand idea.  It means easy compiler construction,
> and an
> easy to understand language format.  Everybody wins, and there's no more
> debate
> on what gets added to the language since simple is king - if anything,
> there's
> debate on what should be taken out in favor of a more rudimentary syntax.
>
> In practice it fails miserably*, since coders are *always* in the game of
> creating shortcuts.  This is why we write libraries, adopt design
> principles
> like encapsulation and OOP, and press for more concise ways to express
> common
> idioms in the D language itself.  So we choose classes over structs
> w/func-pointers and switch() over elaborate if/else statements where
> appropriate, even though they're functionally equivalent.

(switch() does a table look-up or a binary search, so it really stands on its own.)

> So ultimately you have all kinds of functional overlap in D *everywhere*,
> because every bit of overlap is done with some additional features that
> cover
> yet more use-cases and idioms.  Please understand that I'm not advocating
> that D
> become this bloated monster mismash of features, but I hold onto the
> certainty
> that there is a balance point that allows for some healthy redundancy.

I totally agree.

I must admit that my original post was highly emotional. Just thought the code that I've encountered should have been illegal to begin with.

I also agree that ?: has its uses, but I wonder if it can be limited to select 1 of 2 constants / literals. I mean, could the grammar be changed to only allow constants / literals after the ?.

L.

>When I'm writing libraries, I tend to give longer, complicated names to functions that are slow. People using libraries don't know the performance of a function, and with all that intellisense stuff, they don't read the docs. If you have an array and want to check whether it contains item X, they select "Contains(X)" from the intellisense popup and that's that. I had to rename the function to get it through to them that you don't want to be calling Contains(X) (doing a linear search) in an inner loop :S
Hmm, you have the point here. However, I doubt many people use the same method, AFAIK, most folks use names to make clear what the function does and docs or comments or source code to explain how it is done.

Ivan Kazmenko.

Lionello Lunesu wrote:
> Stewart Gordon wrote:
<snip>
>> Useless?  I've put it to plenty of use.  So have many C programmers, some of which have moved on to D.
> 
> ??? I've multiple inheritance to use, "so have many C++ programmers, some of which have moved to D."

?: is a much simpler feature to implement than MI.

> By useless I meant that it can be replaced by if/else, so it does not fill in a void.

Consider a case where a more complicated expression may have a ?: expression within it.  Then can you think of a way of writing it instead that's nearly as concise?

>> Slow?  I'm surprised.  Do you have a benchmark?
> 
> Just as slow as if/else:
<snip>

Then why not remove if/else because it's slow?

Moreover, language features are not "slow".  What may be slow, however, is the code generated by a particular compiler to implement a particular  language feature.

Stewart.