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

"Possibly" sounds encouraging.
I was thinking along the lines that if the two or more words could be
done with spaces then somehow it would be seen *only* when all the group
were present, like when part of a keyword is written into the CodeMax
editor it shows that the keyword is not all there (also if written
wrong) by not switching color. So if all the words were present in
proper placement (and spelling) it would be recognized and only then.


Ron Parker wrote:
> 
> >I had previously writ:
> >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.

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

Post a reply to this message

'sor' is surface of revolution though. Of course I understand your
sentiment, writing a word out is more obvious. Especially difficult to
recall all the keywords if each and every were short versions. Except I
still could see getting along with several at least. superellipsoid is
one, especially; maybe 'sel'?. Ones like prism are fine.

Got 98 cents for a dollar?


Margus Ramst wrote:
> 
> 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

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

Post a reply to this message

Spider schrieb in Nachricht <36D2CD37.BED49543@bahnhof.se>...
>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

I've been thinking along the same lines last night. We can access a vector's
x, y and what-not, but we can't access an object's elements like that. I
would really have been glad to have something like camera1.position.x and
camera1.look_at.y or for an Escher pic I was working on.

(Must be our Delphi background, I suppose <heh>.)

--
Rudy Velthuis

Post a reply to this message