On Mon, 22 Feb 1999 14:46:03 -0500, Nathan Kopp <Nat### [at] Koppcom> wrote:
>Rudy Velthuis wrote:
>> 
>> Anyway, can't wait to test the alpha. Don't care about the syntax, as long
>> as I can use it. There are many syntax issues in POV-Ray I don't like (too C
>> oriented <g>), so I don't care about one or two more. I particularly hate
>> the keywords with an underscore in it (look_at etc.).
>> 
>
>Anyone else out there have any opinions on this... right now I have a lot of
>keywords WITH underscores... my reason for this is that the more specific
>I make the keyword, the less likely it will be that it conflicts with
>somebody's variable name.  You know... now that I think about it, maybe I
>should ditch some of those extra-long keywords.  (One of the reasons I
>dislike COBOL is the long keywords.)  If somebody wants to use one of my
>reserved words for a variable name, too bad.  ;-)

The proper thing to do here is for everyone writing scenes, inc files, etc.
to use at least one capital letter in every variable name.  My personal
patches (as opposed to the ones I've borrowed from various other people)
always have short, common keywords.  

Keeping in mind that all keywords need to be lowercase, then, it seems
that the underscore is the best alternative to BiCaps.

Post a reply to this message

How about giving us the new keywords and a little about what they
control and we could probably come to a consensus?  Either that, or just
think to yourself, if I was just using the program and not writing it,
what would make sense to me.

I think some good examples are the keywords for radiosity.  Like
grey_threshold could just be grey.  100% grey is no color.  Simpler but
makes sense.  I think minimum_reuse could just be reuse.

I agree with Ron that it's customary for reserved keywords to use all
lowercase and user defined terms should start with a Cap.  So be
specific.  People can change variable names that conflict with them;
that's what the message window is for. ;)

-Mike

> Anyone else out there have any opinions on this... right now I have a lot of
> keywords WITH underscores... my reason for this is that the more specific
> I make the keyword, the less likely it will be that it conflicts with
> somebody's variable name.  You know... now that I think about it, maybe I
> should ditch some of those extra-long keywords.  (One of the reasons I
> dislike COBOL is the long keywords.)  If somebody wants to use one of my
> reserved words for a variable name, too bad.  ;-)
> 
> -Nathan

Post a reply to this message

Mike wrote:
> 
> How about giving us the new keywords and a little about what they
> control and we could probably come to a consensus?  Either that, or just
> think to yourself, if I was just using the program and not writing it,
> what would make sense to me.
> 
> I think some good examples are the keywords for radiosity.  Like
> grey_threshold could just be grey.  100% grey is no color.  Simpler but
> makes sense.  I think minimum_reuse could just be reuse.
> 
> I agree with Ron that it's customary for reserved keywords to use all
> lowercase and user defined terms should start with a Cap.  So be
> specific.  People can change variable names that conflict with them;
> that's what the message window is for. ;)
> 
> -Mike

What Mike said !

Ken would like to pipe in quickly with a plea for shorter keywords and no
under_scored identifiers. The sooner they are fazed out of exsistence
the better.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Mike wrote:
> 
> How about giving us the new keywords and a little about what they
> control and we could probably come to a consensus?  Either that, or just
> think to yourself, if I was just using the program and not writing it,
> what would make sense to me.
> 
> I think some good examples are the keywords for radiosity.  Like
> grey_threshold could just be grey.  100% grey is no color.  Simpler but
> makes sense.  I think minimum_reuse could just be reuse.
> 
> I agree with Ron that it's customary for reserved keywords to use all
> lowercase and user defined terms should start with a Cap.  So be
> specific.  People can change variable names that conflict with them;
> that's what the message window is for. ;)
> 
> -Mike

I agree with the abovesaid.
I really don't have a problem with underscores; you could make your keywords
start with sth. unique like photon_* so they would be unlikely to conflict
with variables. However, it's easy for people to change their variables.
Only please, avoid mega-long keywords! I can rarely write max_trace_level in
one go without typos.

Margus

Post a reply to this message

On Tue, 23 Feb 1999 11:36:14 +0200, Margus Ramst <mar### [at] peakeduee> wrote:
>I agree with the abovesaid.
>I really don't have a problem with underscores; you could make your keywords
>start with sth. unique like photon_* so they would be unlikely to conflict
>with variables. However, it's easy for people to change their variables.
>Only please, avoid mega-long keywords! I can rarely write max_trace_level in
>one go without typos.

What about catmull_rom_sphere_sweep?  :)

Post a reply to this message

crss {}
I like abreviation. I'll vote yea on the short keywords too, and the
underscore removal.
Any idea about making spaces available between keywords? Plausible
(doable I don't know) to make a keyword recognisable (oops, my Canadian
sp.) which goes as a pair of words or more? ie. max trace level, or do
they have to be a solid string in the C programming language
definitions? Hey, how would this be for something in POV-Ray script too?
Good idea, but not possible?

Mental note: too many questions at once may appear to inquisitive ;)


Ron Parker wrote:
> 
> On Tue, 23 Feb 1999 11:36:14 +0200, Margus Ramst <mar### [at] peakeduee> wrote:
> >I agree with the abovesaid.
> >I really don't have a problem with underscores; you could make your keywords
> >start with sth. unique like photon_* so they would be unlikely to conflict
> >with variables. However, it's easy for people to change their variables.
> >Only please, avoid mega-long keywords! I can rarely write max_trace_level in
> >one go without typos.
> 
> What about catmull_rom_sphere_sweep?  :)

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

On Tue, 23 Feb 1999 12:32:51 -0600, Bob Hughes <inv### [at] aolcom> wrote:
>crss {}

I asked about that one because it's one of the longer new keywords 
in the superpatch.  Obviously, it's not one of mine.  I don't change
other people's keywords for compatibility's sake, unless there's a
conflict (the #macro stuff from the iso patch, for example.)

>Any idea about making spaces available between keywords? Plausible
>(doable I don't know) to make a keyword recognisable (oops, my Canadian
>sp.) which goes as a pair of words or more? 

Possible but ugly, since the tokenizer splits things on spaces.  Even if
you did make it work with the current tokenizer (and you could, I think)
you'd get weird error messages if you said something like "max trace 10" 
instead of "max trace level 10"  All in all, probably not a good thing.

Post a reply to this message

Nathan Kopp schrieb in Nachricht <36D1B3FB.1B063D3B@Kopp.com>...

>Anyone else out there have any opinions on this... right now I have a lot
of
>keywords WITH underscores... my reason for this is that the more specific
>I make the keyword, the less likely it will be that it conflicts with
>somebody's variable name.  You know... now that I think about it, maybe I
>should ditch some of those extra-long keywords.  (One of the reasons I
>dislike COBOL is the long keywords.)  If somebody wants to use one of my
>reserved words for a variable name, too bad.  ;-)

Exactly. Ditch the underscores. They look unprofessional somehow. I've never
seen a language using *keywords* with underscores. But I don't know them
all.

--
Rudy

Post a reply to this message

Bob Hughes wrote in message <36D2F453.BFCE1758@aol.com>...
>crss {}


I think you're going to extremes here. If all keywords had only 3-5 chars,
it would be impossible (for me, at least) to memorize them. The name should
have at least some connection with the function.
And_what's_wrong_with_underscores_anyway?

Margus

Post a reply to this message

While we're at it, when will someone do a OOP-POV ???
dot separated keywords and so on.
int photon.mapsize
int photon.level
vector camera.look_at
vector camera.postition

Well, I think it would be useful in some cases, and less so in
others.(as is most things)



Mike wrote:
> 
> How about giving us the new keywords and a little about what they
> control and we could probably come to a consensus?  Either that, or just
> think to yourself, if I was just using the program and not writing it,
> what would make sense to me.
> 
> I think some good examples are the keywords for radiosity.  Like
> grey_threshold could just be grey.  100% grey is no color.  Simpler but
> makes sense.  I think minimum_reuse could just be reuse.
> 
> I agree with Ron that it's customary for reserved keywords to use all
> lowercase and user defined terms should start with a Cap.  So be
> specific.  People can change variable names that conflict with them;
> that's what the message window is for. ;)
> 
> -Mike
> 
> > Anyone else out there have any opinions on this... right now I have a lot of
> > keywords WITH underscores... my reason for this is that the more specific
> > I make the keyword, the less likely it will be that it conflicts with
> > somebody's variable name.  You know... now that I think about it, maybe I
> > should ditch some of those extra-long keywords.  (One of the reasons I
> > dislike COBOL is the long keywords.)  If somebody wants to use one of my
> > reserved words for a variable name, too bad.  ;-)
> >
> > -Nathan

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message