Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Commands

Author
Message
Mike Johnson
TGC Developer
22
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 18th Jan 2011 16:58 Edited at: 18th Jan 2011 17:04
Link
We're looking for some feedback with regards to the command structure within App Game Kit (for the scripting side). Currently we're leaning towards something like this:



It's very similar to the existing structure of DB Pro commands, with the difference being no spacing in the command names. The alternative is more like a DB Pro command with a space being used:



AGK has been written to cope with either method, but it's better to pick one to avoid confusion. What are your thoughts on this? Do you prefer no spacing or spacing in commands?
Back to top
Profile PM Email Website
Drakkheim
14
Years of Service
User Offline
Joined: 7th Oct 2010
Location: TX
Posted: 18th Jan 2011 17:04
Link
No spacing just nice and consistent camel case. Pleeease no spacing, or maybe make it optional?
Back to top
Profile PM Website
DeepIndian
13
Years of Service
User Offline
Joined: 18th Jan 2011
Location: USA
Posted: 18th Jan 2011 17:05
Link
Please NO SPACING!!!!
Back to top
Profile PM Email
Scraggle
Moderator
21
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 18th Jan 2011 17:05 Edited at: 18th Jan 2011 17:06
Link
My personal preference would be for spacing

Can I also ask for a bit more consistency with naming conventions than DBP has please?
For example:

Might be better as:


Obviously these are 3D and not relevant to the App Game Kit but you get the idea



Back to top
Profile PM Email
Mike Johnson
TGC Developer
22
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 18th Jan 2011 17:06
Link
Consistency of commands is something we have been discussing. We're going through the list making sure it's much better this time round.
Back to top
Profile PM Email Website
Talairina
18
Years of Service
User Offline
Joined: 9th Jan 2006
Location: United Kingdom
Posted: 18th Jan 2011 17:44
Link
Spacing would be nice. Makes for easier reading. Granted some people can adjust to reading non-spaced commands over time but I'm one of those that can't. So spacing would be appreciated it.
Back to top
Profile PM
Mnemonix
21
Years of Service
User Offline
Joined: 2nd Dec 2002
Location: Skaro
Posted: 18th Jan 2011 17:49
Link
Personally, coming from a c# / c++ development back into a BASIC style development, I would prefer the commands to be as in the first example.

Join us at www.devhat.net and in #lobby at irc.devhat.net
Back to top
Profile PM Email Website
Link102
19
Years of Service
User Offline
Joined: 1st Dec 2004
Location: On your head, weeeeee!
Posted: 18th Jan 2011 17:53 Edited at: 18th Jan 2011 17:54
Link
No spacing and brackets if you ask me. After a while people will use alot of their own functions (which have brackets) anyway.



or am I going the wrong way here? o.o

Back to top
Profile PM
Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 18th Jan 2011 18:00 Edited at: 18th Jan 2011 18:01
Link
Having done a couple of things in DBPro recently after coming from a C++ background there is one thing I find a little confusing, you can end up with commands looking like this:



Its not apparent at first glance what is going on, I think no spacing would help with this problem. One step further would be to always use brackets for command parameters but that may be another issue.

EDIT: OK, link beat me to it in the post above.

fulcrum physics - free collision/physics plug-in for DarkGDK
Back to top
Profile PM Email
foleypro
19
Years of Service
User Offline
Joined: 3rd Jun 2005
Location: Tacoma Washington USA
Posted: 18th Jan 2011 18:15 Edited at: 18th Jan 2011 18:16
Link
Just Poppin in and making sure I get this app...

As Always B3D....www.fnggames.com

Back to top
Profile PM Email Website
Cyborg ART
17
Years of Service
User Offline
Joined: 14th Jan 2007
Location: Sweden - Sthlm
Posted: 18th Jan 2011 18:53
Link
I would say no spaces, even tough I am used to spaces.

Back to top
Profile PM Email Website
C0wbox
18
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 18th Jan 2011 18:55 Edited at: 18th Jan 2011 18:57
Link
Have an overly large number of commands that all do the same just to make sure everyone can use it !

Have:

You can't go wrong ! - And everyone's code, even if they copy other people's projects exactly will still likely be different.

Back to top
Profile PM Email Website
Scraggle
Moderator
21
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 18th Jan 2011 19:00
Link
After seeing this:


I have decided to change my vote to NO spaces.



Back to top
Profile PM Email
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 18th Jan 2011 19:11
Link
I'd prefer something like functions are in C (no spaces, always bracketed, and returning either a type or 'void'), but with case-insensitivity.

The problem with case-sensitive names is getting the case right - is it rgb, Rgb, or RGB?

Having no spaces, makes it easier to write tools that understand the code, and standardisation on brackets makes that even easier.

Get the latest Matrix1Utility plug-ins (23-DEC-2010)
Back to top
Profile PM Email Website
Mike Johnson
TGC Developer
22
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 18th Jan 2011 19:12
Link
matty, the line of code you showed is the main reason why I dislike spaces.
Back to top
Profile PM Email Website
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 18th Jan 2011 19:53 Edited at: 18th Jan 2011 19:56
Link
I agree with matty halewood's reason for NO SPACES. It took me a long time when I was learning DBPro (and even now on occasion) to realize that two commands were involved in statements like his example.

Can we make them case sensitive as well so that you must use things like LoadImage (or loadImage) rather than LOADIMAGE or loadimage. It makes a big difference to the readability of some long commands.

[I'm glad Scraggle now agrees with the NO SPACES position. I was beginning to doubt his sanity. ]

Edit (to IanM)

Quote: "The problem with case-sensitive names is getting the case right - is it rgb, Rgb, or RGB?"


Why is that a problem? The same principle applies. The first letter of each word should be capitalised - and RGB is an abbreviation of course.
Back to top
Profile PM Email
sladeiw
15
Years of Service
User Offline
Joined: 16th May 2009
Location: UK
Posted: 18th Jan 2011 20:03
Link
Although I'm unlikely to use this I also hate spaces in dbpro's commands. Definitely camelCase, and like GG said uppercase commands are less readable. (Just as any text in uppercase) The IDE could auto-correct the case whatever the user types if it's purely for readability.
Back to top
Profile PM
Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 18th Jan 2011 20:20
Link
Quote: "Can we make them case sensitive as well so that you must use things like LoadImage (or loadImage) rather than LOADIMAGE or loadimage. It makes a big difference to the readability of some long commands."


This is best done at source level through the IDE.


Hmm, I wonder what's coming in 2011?
Back to top
Profile PM Website
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 18th Jan 2011 20:30
Link
@GG,
In English, it's wrong to do so, but when coding, quite a few professional programmers take abbreviations and capitalise the first letter only, simply because it makes the names easier to read when you have no spaces separating words (which seems to be a common consensus here).

Not too much difference in readability here:
ConvertKMToMiles
ConvertKmToMiles

Big difference here:
RGBToHSV
RgbToHsv

@Kevin,
So you'd go with case-corrected, taking it out of the programmers hands?

Get the latest Matrix1Utility plug-ins (23-DEC-2010)
Back to top
Profile PM Email Website
sladeiw
15
Years of Service
User Offline
Joined: 16th May 2009
Location: UK
Posted: 18th Jan 2011 20:47
Link
Quote: "So you'd go with case-corrected, taking it out of the programmers hands?"


Unless the programmer could choose their preference and the IDE auto-corrected it, best of both worlds
Back to top
Profile PM
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 18th Jan 2011 20:57
Link
Definitely no spaces! Aside from the readability problems, spaces in commands is the cause of about 50% of the bugs in DBPro IDEs

Also, always have brackets, like IanM said. (Again, for both readability, and IDE support)

Case sensitivity is a tricky one, but I'd say to go case sensitive, but with autocomplete in the IDE which will find the command regardless of case, like in VC++ (so it actually requires you to press tab to fix the case rather than doing it automatically. Automatically would be very annoying).

It would be nice to get some guidelines for naming conventions, programming style, etc. for user code as well, so that everyone who follows the guidelines will have consistent code.

Finally, this is unrelated, but PLEASE make it so that each source file compiles to its own object file before they are linked! It would improve compile times for large projects dramatically.

[b]
Back to top
Profile PM Email Website
Yodaman Jer
User Banned
Posted: 18th Jan 2011 21:23 Edited at: 18th Jan 2011 21:24
Link
No spaces please. After dabbling in C++ it just makes sense!

Same with brackets. That'd make things a little easier. I'm also not sure on case sensitivity, but I definitely like the looks of commands looking like this:



Now that I re-read that, it reminds me of BlitzBasic...which brings me to another thing....

If AppGameKit does eventually go 3D (or does it already?), do we HAVE to assign 3D objects and images numbers? Or will there be a different way to reference them? Just wonderin'.

Back to top
Profile
_Pauli_
AGK Developer
15
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 18th Jan 2011 21:29
Link
My vote is definitly for:

- No spaces
- Allways brackets
- Case-sensitive

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
kamac
13
Years of Service
User Offline
Joined: 30th Nov 2010
Location: Poland
Posted: 18th Jan 2011 21:45
Link
No spaces and always bracket's, that's what i vote for

Cheers!

~Kamac
Back to top
Profile PM Email
Rampage
16
Years of Service
User Offline
Joined: 4th Feb 2008
Location: New Zealand
Posted: 18th Jan 2011 22:08 Edited at: 18th Jan 2011 22:15
Link
- No spaces
- Always brackets around parameters
- Case-sensitive
- Case-Corrected

Much cleaner looking code in my opinion. Feels more programmy like
Would be splendid


Eidos!
Back to top
Profile PM Email Website
Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 18th Jan 2011 22:24
Link
@Ian

Quote: "So you'd go with case-corrected, taking it out of the programmers hands?"


I don't understand the question ?


Hmm, I wonder what's coming in 2011?
Back to top
Profile PM Website
Flatlander
FPSC Tool Maker
17
Years of Service
User Offline
Joined: 22nd Jan 2007
Location: The Flatlands
Posted: 18th Jan 2011 22:33 Edited at: 19th Jan 2011 05:41
Link
No spaces.
As far as brackets, either

brackets if it is a function that returns a value. No brackets if it is a subroutine that does not return a value.

OR

brackets always.

Prefer former; but can cope with latter.

As far as upper/lower case. I like a combination when there are no spaces. I also like the IDE's of other languages that will auto correct. That way I can just type all lower case and then it will be corrected. This also is valuable to determine if the command verbiage is spelled correctly. I also like to create my own variables with a combination of upper and lower case and it too be auto corrected.

All-in-all, whatever the decision, one will need to just simply get used to it.
Back to top
Profile PM Email
Mr Bigglesworth
16
Years of Service
User Offline
Joined: 4th Mar 2008
Location:
Posted: 18th Jan 2011 22:33 Edited at: 18th Jan 2011 22:36
Link
Quote: "- No spaces
- Always brackets around parameters
- Case-sensitive
- Case-Corrected"


I second this, after using C++ and C# having grouping symbols and non-spaced, case sensitive commands makes the readibilty easier and it is easier to trace through the code to find user made coding errors.
Back to top
Profile PM Email
tiresius
22
Years of Service
User Offline
Joined: 13th Nov 2002
Location: MA USA
Posted: 18th Jan 2011 22:36
Link
Quote: "- No spaces
- Always brackets around parameters
- Case-sensitive
- Case-Corrected"

Agree.


A 3D marble platformer using Newton physics.
Back to top
Profile PM Email
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 18th Jan 2011 22:53
Link
@Kevin,
Quote: "Quote: "So you'd go with case-corrected, taking it out of the programmers hands?"

I don't understand the question ?"

Simply that no matter what the programmer types, that the IDE will automatically parse the line and correct all case of commands/functions/variables etc when he/she hits the enter key or moves from the line in some way.

Get the latest Matrix1Utility plug-ins (23-DEC-2010)
Back to top
Profile PM Email Website
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 18th Jan 2011 23:13
Link
Returning to the abbreviations issue, I find the correct versions of your examples easier to read, i.e.

ConvertKmToMiles (since kilometre is one word)

and

RGBToHSV (but I agree the RGBT bit looks awkward - why not RGB2HSV?).

I don't like the idea of autocomplete/autocorrection. I find it confusing to have something other than what I want flashed up in front of me while typing. But that's probably a very personal view.

However both these issues are minor and I agree with Flatlander's comment: "All-in-all, whatever the decision, one will need to just simply get used to it."

But, please, no spaces.
Back to top
Profile PM Email
thenerd
15
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 18th Jan 2011 23:38
Link
Quote: "- No spaces
- Always brackets around parameters
- Case-sensitive
- Case-Corrected"

I agree, except I don't think it should need to be case sensitive.

Back to top
Profile PM Email
Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 19th Jan 2011 00:00
Link
@Ian,

Quote: " Simply that no matter what the programmer types, that the IDE will automatically parse the line and correct all case of commands/functions/variables etc when he/she hits the enter key or moves from the line in some way."


If the back end are to be case sensitive, then it makes more sense for the IDE to 'assist' programmers as much as possible (case correction, auto completion).

If it's not case sensitive, then the user/IDE could tweak the style however they please. It's irrelevant.


Hmm, I wonder what's coming in 2011?
Back to top
Profile PM Website
swissolo
14
Years of Service
User Offline
Joined: 9th Jan 2010
Location:
Posted: 19th Jan 2011 00:05
Link
No spaces, or I guess you could optionally use _ to keep it one "word", Brackets, and consistency is really important. I don't really care for case-sensitivity, just makes it more work to code.

swis
Back to top
Profile PM
knxrb
FPSC Tool Maker
16
Years of Service
User Offline
Joined: 10th Oct 2008
Location: United Kingdom
Posted: 19th Jan 2011 00:21 Edited at: 19th Jan 2011 00:24
Link
I say:
Spaces for faster typing (and my personal preference).
Brackets for easy identification of when a command ends and the arguments start.
Auto correction for case sensitivity.
Auto completion for faster command typing (Checkbox to turn it on and off).
Spell check for misspelled commands.

knxrb
Back to top
Profile PM Email Website
Libervurto
18
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 19th Jan 2011 00:58 Edited at: 19th Jan 2011 01:06
Link
Wah, lots of discussioning!

I agree that spaces in the middle of commands are ugly and difficult to follow. I'd even take it further and suggest that instead of set object wireframe obj,1 we'd write the same thing like this obj.wireframe = 1.
So objects are a type, I feel like DB is progressing towards this kind of syntax anyway. This works nicely because we can think of the wireframe property of the object in the same way as a variable.

This is sort of the same argument as changing let x=1 to x=1

Oh and while we're at it please have a different symbol for assignment and comparison operations, using "=" for both is always confusing.

I'd love to see some sort of code block implementation, what I mean is like in C where everything between {} is considered part of the same block to be executed. This could also solve the problems that sometimes crop up because DB has no end-of-line symbol, if we could use blocks we could string lines together and still avoid using an end-of-line symbol. eg
Quote: "
If i = 1 {
print "Hi"
i=2
cls
print "Howdy!"
}
"



Everything worthwhile requires effort.
Back to top
Profile PM Email
CumQuaT
AGK Master
14
Years of Service
User Offline
Joined: 28th Apr 2010
Location: Tasmania, Australia
Posted: 19th Jan 2011 01:09
Link
Personally I believe that the closer you keep it to original DBpro commands, the better people will be able to swing into it.

Malevolence: The Sword of Ahkranox
The infinite RPG
http://www.msoa-game.com
Back to top
Profile PM Email
The Slayer
Forum Vice President
15
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 19th Jan 2011 02:08
Link
Quote: "Personally I believe that the closer you keep it to original DBpro commands, the better people will be able to swing into it."

Yeah, that's my thought aswell. The spacing or non-spacing is more a personal preference, so maybe make 'em both possible. Just don't make this into a language that has to be learned from the ground up.

Cheers

SLAYER RULES! YEAH, MAN!!
Back to top
Profile PM Email
Mr Bigglesworth
16
Years of Service
User Offline
Joined: 4th Mar 2008
Location:
Posted: 19th Jan 2011 02:23 Edited at: 19th Jan 2011 02:23
Link
Hmm, I like using the types. Something like texturing and object could be like this:

object.texture(object, texture)

Or you could set it up like a C style language and use the namespace "object".
object::texture(object, texture);

Although it probaly wouldn't be a good idea to use namespaces for multiple reasons
Back to top
Profile PM Email
Brk_oth
19
Years of Service
User Offline
Joined: 8th Aug 2005
Location: Australia
Posted: 19th Jan 2011 05:37
Link
- No spaces within commands
- Always brackets around command parameters
- Case-insensitive commands

No signature found...
Back to top
Profile PM
ShaunRW
DBPro Developer
16
Years of Service
User Offline
Joined: 7th Jan 2008
Location: Brisbane, Australia
Posted: 19th Jan 2011 05:56
Link
- No Spaces
- Case-sensitive
- Correct case sensitivity


ShaunRWs Timer Plugin.
Back to top
Profile PM Email
Flatlander
FPSC Tool Maker
17
Years of Service
User Offline
Joined: 22nd Jan 2007
Location: The Flatlands
Posted: 19th Jan 2011 05:56 Edited at: 19th Jan 2011 06:01
Link
I said, "I also like the IDE's of other languages that will auto correct" Green Gandalf said, "I don't like the idea of autocomplete/autocorrection."

I made a mistake with using the term "auto correct." I didn't mean auto correct. I dislike that as well and agree with GG about that. Also, I don't think it should actually correct it. Not a good idea. What I was trying to say is, for example. If you type global when defining a global variable and then you proceed to a different line (either up or down), it will change the command to Global. This tells me I typed it right and continue on with the code without going back to chang it. It is really helpful to me. Sorry for the confusion about using the wrong word.

Maybe that's what everybody means by "case sensitive." I of case sensitive as if you do not have the case right it will crash on you. I prefer to type in all lower case and let the IDE change it for me after going to a new line -- usually pressing the enter key for a new line.
Back to top
Profile PM Email
Scene Commander
Support Manager
16
Years of Service
User Offline
Joined: 3rd May 2008
Location:
Posted: 19th Jan 2011 09:33
Link
This is a very interesting development and I'm watching this closely

No spaces
Always brackets around parameters
Case-Corrected

Quote: "I prefer to type in all lower case and let the IDE change it for me after going to a new line."


That would be my preference too

http://jimjamsgames.yolasite.com
Back to top
Profile PM Email Website
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 19th Jan 2011 12:35
Link
Also, make it so we have to define variables before using them. This really helps solve typos as most typos are misspelled variable names.

BlitzTerrain 2.00 R2 Released!
Back to top
Profile PM Email Website
Fatal Berserker
14
Years of Service
User Offline
Joined: 2nd Jul 2010
Location:
Posted: 19th Jan 2011 13:27
Link
if you have it OOP than you can utilize intellisense.
eg
Instead of:
set object wireframe obj, 1
set object exclude obj, 1
set object visible obj, 1

You can do:
obj.Wireframe = 1
obj.Exclude = 1;
obj.Visible = true;

Or:
Object.Wireframe(obj,1);
etc.
Its just easier to remember commands with intellisense.

Back to top
Profile PM
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 19th Jan 2011 14:56
Link
It seems no spaces is fairly unanimous, but a compromise on case needs to be reached. How about case insensitive commands, so you can type them however you want, with an IDE option that converts them to LoadImage style for easier reading?
Back to top
Profile PM Email
Scraggle
Moderator
21
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 19th Jan 2011 15:21
Link
That would be my preference (although personally I prefer loadImage to LoadImage).



Back to top
Profile PM Email
dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 19th Jan 2011 16:18 Edited at: 19th Jan 2011 16:20
Link
My time to chime in!

No spaces - This was never a good idea to begin with!

Case-sensitive - There are a few reasons why this should be done. I guess the most important is that filenames in non-Windows OSes are largely case-sensitive, so if you make the language that way then they should 'in-theory' natually keep an eye out for their filenames as to not create massive deployment issues which can't be caught at compile time in all cases(pun!).

Plus, when you say case-insensitive, you're only talking about the English language in the ANSI range, these days you should really be supporting UTF-8(and supporting it is just a case of not not-supporting it), so unless you write the never perfect behemoth that is supporting proper case-insensitivity, then it'll always be partially case-sensitive.

I personally always use upper camel case(LikeThis) for types and functions, but lower camel case(likeThis) for variables. And with the exception of underscores(which haven't even been mentioned here)this approach is virtually standard across all C/C++/Java/whatever code. The only main point of contention you're left with is initialisms and acronyms, I used to do all capitals (RGB, HSV, etc), but I sometimes come across code where I need to have two in a row, this quickly made me change my mind and so ColourHsvRgbWhatever makes far more sense than the alternatives I've seen, so I think that standard should be used.

Brackets around all functions! - This just makes the language far more consistent, in DBPro it made no sense that commands that returned nothing didn't require brackets, but user functions that also returned nothing did. Also, not having brackets could maybe be used to pass functions around in variables? This would allow for callbacks.

I have a lot of ideas for things that go outside of the scope of this topic so maybe I'll make a thread for it!

Back to top
Profile PM Email
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 19th Jan 2011 16:34
Link
No spaces
case-insensitive

And maybe an option to turn on explicit variables, like VB or BasicGL's "use option explicit".

"Only the educated are free" ~Epictetus
"Imagination is more important than knowledge..." ~Einstein
Back to top
Profile PM Email Website
Flatlander
FPSC Tool Maker
17
Years of Service
User Offline
Joined: 22nd Jan 2007
Location: The Flatlands
Posted: 19th Jan 2011 17:07
Link
Quote: "How about case insensitive commands, so you can type them however you want, with an IDE option that converts them to LoadImage style for easier reading? "


Sounds good. Yes.
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-11-24 15:14:07
Your offset time is: 2024-11-24 15:14:07