On Thu, Nov 17, 2005 at 04:05:30AM +0100, Daniel Brockman wrote:
That is, hyphen and underscore are synonymous in identifiers,
but an initial hyphen is not taken to be part of the identifier.
Why not make this feature generic and define equivalence classes for
equivalent characters in an
DB == Daniel Brockman [EMAIL PROTECTED] writes:
DB You may be right about this. I would be happy if the
DB standard distribution came with a package that enabled the
DB hyphenated identifiers syntax in the lexical block:
DBuse hyphenated_identifiers;
DB Hopefully the name of
Uri Guttman [EMAIL PROTECTED] writes:
this idea would need to be worked out in much greater detail. there are
many different identifiers in perl. would all of them be subject to this
change? how would a global work if some other module refered to it using
underscores but your module used
No sane person would put their braces in different places in
different parts of their code, so why don't we just say,
from now on, you must use brace style X?
Have you never seen code that's been worked on by several people with
differing tastes in brace positioning and no coding standard? Have
On Wed, 16 Nov 2005, Daniel Brockman wrote:
No offense to whoever made that suggestion, but I think there are far
more people out there with a developed taste for hyphenated
identifiers than there are people with a thing for using backticks as
subscript operators.
Do you see the difference?
Jan,
No offense either, but if you are suggesting that
@a[$i-1] + @a[$i+1]
should be interpreted as
@a[$i_1] + @a[$i+1]
then I think it is pretty obvious why this is a really bad idea.
That's a very good example. I think I'm going to have to
change my mind and agree that it
On Thu, Nov 17, 2005 at 10:56:27AM +0100, Daniel Brockman wrote:
: That problem is not specific to this feature. For any package
: that changes the syntax, you can ask what about eval?
:
: So... what *about* eval? :-)
Always parses with the parser in effect at that point, the same one you'd
get
I like hyphens. They're easier to type and help
prevent_me_from_Doing_This and generating errors because of case
sensitivity.
On the other hand, consistency of appearance may be a problem for some
people. I often associate code with the way it looks on screen, not
necessarily with what it does or
Sebastian,
I like hyphens. They're easier to type and help
prevent_me_from_Doing_This and generating errors because
of case sensitivity.
On the other hand, consistency of appearance may be a
problem for some people. I often associate code with the
way it looks on screen, not necessarily
On Thu, 2005-11-17 at 05:31 +0100, Daniel Brockman wrote:
This is a very valid concern, but the problem will not arise
unless people start mixing these two styles --- something
which is very obviously not a good idea.
That doesn't mean that people will avoid it, by accident or on purpose.
Daniel Brockman [EMAIL PROTECTED] wrote:
So what is my suggestion? Obviously disallowing underscores
and instead allowing hyphens would just replace one problem
with an even worse problem (not only would there still be
people who don't like hyphens, but it would alienate a large
portion of
Thank you for your considerate reply, Brent.
I see a few syntactic problems with this idea: the subtraction and
negation operators you already mentioned,
Did I miss any problems related to those?
but also the fact that dashes are already used in package names to
indicate version and author
On Thu, 2005-11-17 at 07:27 +0100, Daniel Brockman wrote:
Yet you have the choice of where to put your braces, even
though the braces don't lend themselves to different tasks
depending on whether you put them on a new line or not.
You *don't* have the choice to use different types of braces,
chromatic [EMAIL PROTECTED] writes:
Yet you have the choice of where to put your braces, even
though the braces don't lend themselves to different tasks
depending on whether you put them on a new line or not.
You *don't* have the choice to use different types of
braces, though -- at least
14 matches
Mail list logo
