Archived

This forum has been archived. Please start a new discussion on GitHub.

Slice identifiers cannot contain underscores?

dthomson
dthomson
in Comments
That seems like a slightly strange restriction. What if I don't like bouncy caps names, or want to use the near ubiquitous "types use bouncy caps", "variables and operations use underscores" convention?

For languages where bouncy caps is the official style, this is fine, but for languages where it is not, like C++, Python, Perl, C and so on it's going to lead to ugly, inconsistent code, and probably violate most organisation's coding style rules.

Is there a technical reason to put this restriction in?

Comments

  • rodrigc
    rodrigc
    This is explained on page 141 of the ICE manual
    in the section 4.19.2 CORBA IDL features that
    are missing in ICE.

    The paragraph starts with the section:

    "4. Underscores in identifiers"
  • dthomson
    dthomson
    This is explained on page 141 of the ICE manual

    I know. I just read it. I should have waited a bit before asking.

    But, even so, using this for guaranteed name disambiguation feels like using a sledgehammer to crack a walnut. Every other language I use allows underscores.

    Not that I've got a better solution, mind you :)
  • michi
    michi
    Originally posted by dthomson
    I know. I just read it. I should have waited a bit before asking.

    But, even so, using this for guaranteed name disambiguation feels like using a sledgehammer to crack a walnut. Every other language I use allows underscores.

    Not that I've got a better solution, mind you :)

    Well, consider the alternatives. The fact is that we *must* have some way to avoid name clashes for generated identifiers -- the implementation cannot sensibly be achieved without having a namespace of its own.

    We agonized over this decision for quite a while before we settled on the underscore restriction. Without it, we either would have had the eternal risk of name clashes in the generated code, or we would have to resort to some form of name mangling, which is worse.

    Cheers,

    Michi.
  • Ken Carpenter
    Ken Carpenter
    How about using double underscores for generated identifiers and allowing user identifiers to contain only single underscores? :)



    Ken Carpenter
  • michi
    michi
    Originally posted by Ken Carpenter
    How about using double underscores for generated identifiers and allowing user identifiers to contain only single underscores? :)

    Hi Ken,

    yes, we considered that too. The problem with this is that double undescores are reserved in C++ for the implementation, so we would tread on the compiler's namespace.

    I'm afraid that there is no clean solution to this. Whichever way you turn, you find something unpalatable. In the end, banning underscores seemed the cleanest approach -- at least it guarantees that the all valid Slice definitions can be mapped to valid native language code, and removing the underscores doesn't cause ergonomic problems, as name mangling does.

    Just consider (tongue in cheek): until C came along, the whole world got along just fine in FORTRAN, COBOL, and Pascal without underscores. So, flame away! :-)

    Cheers,

    Michi.
  • Ken Carpenter
    Ken Carpenter
    I see. Triple underscores? ;)

    Anyway, it doesn't bother me, since our coding standard doesn't use underscores.


    Ken Carpenter
  • michi
    michi
    Originally posted by Ken Carpenter
    I see. Triple underscores? ;)

    No, I would suggest quintuple underscores, to be on the safe side ;)

    Anyway, it doesn't bother me, since our coding standard doesn't use underscores.

    Hah! First he makes all this fuzz, and then he admits that it doesn't bother him! ;)

    Cheers,

    Michi.
  • Ken Carpenter
    Ken Carpenter
    Originally posted by michi
    Hah! First he makes all this fuzz, and then he admits that it doesn't bother him! ;)
    <sarcasm>It's just my compassionate nature I guess. When others feel pain I reach out and try to help.</sarcasm>:rolleyes:

    Ken Carpenter
  • bernard
    bernard Jupiter, FL
    You could disallow underscores as the first letter and use leading underscores in the generated code. Or even simpler, since all Ice* identifiers are reserved, prefix all the generated code by Ice or ice (or _ice etc).
    Entirely banning underscores also seems very drastic to me!

    Cheers,
    Bernard
  • michi
    michi
    Originally posted by bernard
    You could disallow underscores as the first letter and use leading underscores in the generated code. Or even simpler, since all Ice* identifiers are reserved, prefix all the generated code by Ice or ice (or _ice etc).
    Entirely banning underscores also seems very drastic to me!

    We considered that. But leading underscores cause problems in C++ because identifiers starting with an underscore and followed by an upper-case letter are reserved for the implementation, as are all identifiers containing two underscores. This isn't idle speculation either -- I remember that, years ago, we changed the CORBA C++ mapping to escape reserved words with a _cpp_ prefix instead of a plain underscore; the reason was that some compilers blew up badly when they found _try or some such as an identifier (as they were entitled to, incidentally).

    Moreover, as soon as we permit underscores in Slice, we'd need yet another mechanism to escape generated identifiers in C++. Yes, Ice is reserved already, but we took that step largely to avoid clashes with modules that support the run time, such as Ice and IceInternal.

    I'm afraid that there really is no good solution to this. Look at it this way: if you consider Ice unusable because Slice identifiers can't contain underscores, there is always CORBA <grin>...

    Cheers,

    Michi.
  • dthomson
    dthomson
    Michi spoke thusly:

    I'm afraid that there really is no good solution to this. Look at it this way: if you consider Ice unusable because Slice identifiers can't contain underscores, there is always CORBA <grin>...

    I don't think anyone minds much per se, provided that there is a reasonable explanation. I'm more than satisified with the reasoning that you have outlined here!

    However, this stuff just isn't in the documentation, and when you read that clause it just comes across as arbitrary. And that, like Wirth and the infamous Modula-2 keyword rules (*), you're just trying to enforce a stylistic convention onto others.

    Since most coders are quite sensitive about their code formatting styles, it would be worth a short paragraph right there broadly outlining the reasons that this restriction has been applied ... so that the reader's blood pressure can return to normal levels ;)

    (*) if you've used this language, all keywords are in upper case, so that every program you write IS SHOUTING LIKE THIS! The reasoning, I hear, was to make keywords stand out. Guess Wirth just didn't see syntax highlighting editors on the horizon :( Nice language, apart from that <flame> ... better than C, anyway </flame>
  • michi
    michi
    Originally posted by dthomson
    Since most coders are quite sensitive about their code formatting styles, it would be worth a short paragraph right there broadly outlining the reasons that this restriction has been applied ... so that the reader's blood pressure can return to normal levels ;)

    Fair enough, that makes sense. I'll add an explanation to the doc, thanks!

    Cheers,

    Michi.

Categories