Re: Why we should (not?) have closures after all

Mark Space <markspace@xxxxxxxxxxxxx> writes:
Patrick May wrote:
HashMap<Long,List<TradeTableRecordEntry>>
Personally, I like this better. It's easy to read and I can see
immediately what's going on.

This shows what, but not why. TradeMap isn't just shorter, it's
more descriptive, which aids in understanding.

I disagree. HashMap is well named, and moreover a well understood
part of the standard API. That tells me quite a lot by itself. And
that it holds trade information is obvious from the well-named
TradeTableRecordEntry.

It tells you something at a different level of abstraction.
Sometimes you want the implementation detail, sometimes you want the
conceptual detail. A typedef facility will allow programmers to use
whichever is most appropriate in their context.

It's that "// ... etc." that's the problem. Code is a cost. It
must be maintained. A typedef facility would reduce the amount of
code that must be created, which is a savings, and the amount that
must be maintained, which is an even larger savings, while increasing
expressiveness, further decreasing maintenance costs.

In this case I disagree. I intended the comment to signify that new
syntax and semantics would be introduced.

That's not what typedefs are for.

Typedefs are lines of code. And one line of code that provides no new
information, semantics or syntax, is a line of code that can be
eliminated.

I agree. Typedefs, however, do provide additional information and
another means for the programmer to express his or her intent.

To me, this is a fundamental problem with the C family of languages:
the amount of extra, low value code in the form of macros and
typedefs.

C macros are particularly limited, but a real macro facility is
quite useful.

Sometimes this extra code is useful, but often it's not, and it's hard
to resist temptation to write that "one line," so in practice it is
often abused.

Do you have an example of how typedef could be abused?

And you can of course assign descriptive names to particular instances
of your classes, which puts the increased expressiveness where is
should be.

Where you prefer it to be is not necessarily where everyone thinks
it should be.

Map<Long,List<TradeTableRecordEntry>> tradeMap =
new HashMap<Long,<List<TradeTableRecordEntry>>();

tradeMap.add( ... );
tradeMap.remove( ... );

Now I have the full definition where I can see it immediately, with
out having to refer to other source files, and I have the expressive
name too. And I saved a useless line of code writing a typedef.

And if you want to pass it to another method? If you want to
change the detailed implementation without changing the interface? If
you want to make the signatures of your methods clearly express your
intent? Sure you can accomplish those goals with additional classes,
but typedef is a convenience.

What I think this boils down to, like I said in my original reply,
is the viewpoints of the participants in the discussion with respect to
the purpose of programming languages. Many Java champions worry about
how to prevent programmers from doing bad things. I want a language
that empowers the programmer and trusts him or her to use that power
well.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@xxxxxxx | (C++, Java, Common Lisp, Jini, middleware, SOA)
.

Relevant Pages

  • Re: Why we should (not?) have closures after all
    ... willing to trust programmers to use those capabilities well. ... the typedef obscures what is actually going on. ... Typedef, used well, can improve the expressiveness of the ... this is what I'd cite as typedef abuse. ...
    (comp.lang.java.programmer)
  • TYPEDEF - Micro Focus and Starndard (was: Discussions of COBOL philospphy
    ... QUITE clear that there definition of "TYPEDEF" is an extension and does NOT ... TYPE clause as specified in the '02 Standard). ... shops to actively promote this and few programmers try and pursue it. ...
    (comp.lang.cobol)
  • Re: RW error (was: Discussions of COBOL philospphy
    ... then those programmers had ILE COBOL and that was the ... know typedef was available. ... completely different language. ...
    (comp.lang.cobol)
  • Re: advantage of using typedefs
    ... >>> implementation details from other programmers. ... precisely because that value can change from platform to ... native machine type, so that programs behave more or less consistently ... in contrast to a typedef like size_t that deliberately ...
    (comp.lang.c)
  • Re: Why we should (not?) have closures after all
    ... That goes beyond the "what" and informs me about what sort of semantics the variable has. ... A typedef facility would reduce the amount of code ... And you can of course assign descriptive names to particular instances of your classes, which puts the increased expressiveness where is should be. ... And I saved a useless line of code writing a typedef. ...
    (comp.lang.java.programmer)
Loading