For those in the CASE discussion
Moderators: dorpond, trevor, Azhrei
- emirikol
- Dragon
- Posts: 708
- Joined: Sun Jan 13, 2008 5:52 pm
- Location: Lakewood, CO North America
- Contact:
Good place to repeat what I noted earlier:
I consider myself the typical non-programmer using maptools.
Whatever the industry standard is for "case" programming should be used. The whole issue of programming macros and whatnot has gotten beyond what 99% of Maptools players will ever even use or care about. For you programmers, I'm happy that there are still issues of contention that you guys can discuss over coffee :_)
You guys have fun with that stuff. We'll be gaming
jh
I consider myself the typical non-programmer using maptools.
Whatever the industry standard is for "case" programming should be used. The whole issue of programming macros and whatnot has gotten beyond what 99% of Maptools players will ever even use or care about. For you programmers, I'm happy that there are still issues of contention that you guys can discuss over coffee :_)
You guys have fun with that stuff. We'll be gaming
jh
Yes, I'm a chiropractor. Gamer fitness at Hafner Chiropractic in Lakewood, CO: http://www.HafnerChiropractic.com
HAHAHA RPTROLL
Anyways to recap.
I think we are now at the point that The Campaign Properties are case sensitive for the moment.
All evals and compares should be Case-Insensitive. My main thinking is that this is not a Data application, we are not entering Customer information that you may want to make sure it is cased correctly. Most of these compares and the like are for the purposes of macros and scripting. I think there is a majority in favor by virtue that most programming and scripting languages are Case insensitive.
C#(C Sharp) is so far the only noted language that is Case sensitive.
Anyways to recap.
I think we are now at the point that The Campaign Properties are case sensitive for the moment.
All evals and compares should be Case-Insensitive. My main thinking is that this is not a Data application, we are not entering Customer information that you may want to make sure it is cased correctly. Most of these compares and the like are for the purposes of macros and scripting. I think there is a majority in favor by virtue that most programming and scripting languages are Case insensitive.
C#(C Sharp) is so far the only noted language that is Case sensitive.
--
Big Mac
Big Mac
I'll say it here again.
The CASE discussion is merely this:
There are two separate issues that got conflated, and I think they should remain separate. String comparison is a VERY different animal from variable usage.
For variable usage, I don't really care. I know that many current and modern programming languages are case sensitive and maptool is currently case sensitive, but Trevor is making a valid point that unless someone can point out a VALID NEED for case sensitivity, it is better for users for it to go away. Better why? Because, and I'll put on my usability-study hat here, the human brain doesn't parse things that finely, very simply put, and case sensitivity makes debugging more difficult.
I will absolutely agree that X should never be the same as x and any programmer who writes variables in changing case should be shot, but the truth is we want new folks to pick up maptool and write macros. It is NOT supposed to be a 'developer only' tool. A certain degree of self-selection will occur on that degree.
For string comparison, I think it would be nice to have two ways to make the comparison, but again, trevor makes the valid point that I no one has yet to demonstrate an instance where there is an ABSOLUTE NEED for case-sensitive usage. As in why is Strength functionally different from strength in ANY game system. Show him that, and he'll probably be more will to go that route, I'd guess.
So I think the real question: do we have any game systems what were silly enough to use the same name for something but just changed the case?
I think i've got something tickling my brain on those lines, but I can't remember for sure...
I'll be back around if I remember it.
The CASE discussion is merely this:
There are two separate issues that got conflated, and I think they should remain separate. String comparison is a VERY different animal from variable usage.
For variable usage, I don't really care. I know that many current and modern programming languages are case sensitive and maptool is currently case sensitive, but Trevor is making a valid point that unless someone can point out a VALID NEED for case sensitivity, it is better for users for it to go away. Better why? Because, and I'll put on my usability-study hat here, the human brain doesn't parse things that finely, very simply put, and case sensitivity makes debugging more difficult.
I will absolutely agree that X should never be the same as x and any programmer who writes variables in changing case should be shot, but the truth is we want new folks to pick up maptool and write macros. It is NOT supposed to be a 'developer only' tool. A certain degree of self-selection will occur on that degree.
For string comparison, I think it would be nice to have two ways to make the comparison, but again, trevor makes the valid point that I no one has yet to demonstrate an instance where there is an ABSOLUTE NEED for case-sensitive usage. As in why is Strength functionally different from strength in ANY game system. Show him that, and he'll probably be more will to go that route, I'd guess.
So I think the real question: do we have any game systems what were silly enough to use the same name for something but just changed the case?
I think i've got something tickling my brain on those lines, but I can't remember for sure...
I'll be back around if I remember it.
0+0=1, for very unstable CPUs.
Er, Java and PHP have both been mentioned....Big_Mac wrote:HAHAHA RPTROLL
Anyways to recap.
I think we are now at the point that The Campaign Properties are case sensitive for the moment.
All evals and compares should be Case-Insensitive. My main thinking is that this is not a Data application, we are not entering Customer information that you may want to make sure it is cased correctly. Most of these compares and the like are for the purposes of macros and scripting. I think there is a majority in favor by virtue that most programming and scripting languages are Case insensitive.
C#(C Sharp) is so far the only noted language that is Case sensitive.
0+0=1, for very unstable CPUs.
oops missed them.Orchard wrote:Er, Java and PHP have both been mentioned....Big_Mac wrote:HAHAHA RPTROLL
Anyways to recap.
I think we are now at the point that The Campaign Properties are case sensitive for the moment.
All evals and compares should be Case-Insensitive. My main thinking is that this is not a Data application, we are not entering Customer information that you may want to make sure it is cased correctly. Most of these compares and the like are for the purposes of macros and scripting. I think there is a majority in favor by virtue that most programming and scripting languages are Case insensitive.
C#(C Sharp) is so far the only noted language that is Case sensitive.
--
Big Mac
Big Mac
- Brigand
- Read-only User
- Posts: 1623
- Joined: Thu Feb 14, 2008 8:57 am
- Location: Nosy GM's can go frak themselves!
lowercase and uppercase functions would fix the issues with string comparisons. I'm used to using them from NWN scripting. And as others have said, the average user wouldn't be writing their own scripted macros from scratch. They would be copying and altering pre-written macros for their chosen game system.
- jfrazierjr
- Deity
- Posts: 5176
- Joined: Tue Sep 11, 2007 7:31 pm
Wrong by a huge long shot. Though I have no way to say this with certainty, I expect that case sensitive languages are far more prevalent that those that ignore case.Big_Mac wrote:HAHAHA RPTROLL
Anyways to recap.
I think we are now at the point that The Campaign Properties are case sensitive for the moment.
All evals and compares should be Case-Insensitive. My main thinking is that this is not a Data application, we are not entering Customer information that you may want to make sure it is cased correctly. Most of these compares and the like are for the purposes of macros and scripting. I think there is a majority in favor by virtue that most programming and scripting languages are Case insensitive.
C#(C Sharp) is so far the only noted language that is Case sensitive.
Case Sensitive Languages:
C
C++
C#
Java
Perl
Ruby?
Python
While this is in no way to diminish any language not on this list, I would guess that these languages represent 90%+ of any new software projects in the world today.
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.
Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..
Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..
Ah Sweet. Good to know for me. Like I said on the other thread I am a Data guy now. SO I am way rusty with any thing remotely associated with regular programming. The closet is my scripting for DMGenie I have done.jfrazierjr wrote:Wrong by a huge long shot. Though I have no way to say this with certainty, I expect that case sensitive languages are far more prevalent that those that ignore case.Big_Mac wrote:HAHAHA RPTROLL
Anyways to recap.
I think we are now at the point that The Campaign Properties are case sensitive for the moment.
All evals and compares should be Case-Insensitive. My main thinking is that this is not a Data application, we are not entering Customer information that you may want to make sure it is cased correctly. Most of these compares and the like are for the purposes of macros and scripting. I think there is a majority in favor by virtue that most programming and scripting languages are Case insensitive.
C#(C Sharp) is so far the only noted language that is Case sensitive.
Case Sensitive Languages:
C
C++
C#
Java
Perl
Ruby?
Python
While this is in no way to diminish any language not on this list, I would guess that these languages represent 90%+ of any new software projects in the world today.
--
Big Mac
Big Mac
- thelevitator
- Dragon
- Posts: 963
- Joined: Wed May 17, 2006 2:10 pm
- Location: "The Biggest Little City In The World!"
- Contact:
I'm not a programmer, but I think I am one of the original 50 members of this forum. I've been using this program since at least 1.1, maybe even before. I have to say that I'm a bit wary of how MT has been evolving over the last 6 months. It feels like the program is starting to be developed on the assumption that people have to be programmers to enjoy the full features of the program. It's starting to make this long-time user and idea contributor feel pretty left out.
I'm all for the development of new features and the evolution of this program. What I'm not comfortable with is the seemingly increasingly separatist attitude that is making people like me feel like idiots for not being programmers. I'm starting to get the message that only the elite coders of the world will be able to use this program, and that people like me will be groveling at their feet for help on getting the functionality we want and have access to all of the goodies. I understand that in the development phase, that certain protocol must be followed for consistency, and that things will usually start out more complex to then be refined and streamlined for us "average" users.
What I don't care for is my personal sense that MT is turning into a 2 class program; where the elites get to use all of the goodies and us average users are stuck begging for scraps from the big table.
My ultimate hope is that once everyone agrees on the structure, that some effort will be made to make the program accessible to non-programmers who don't want to have to depend on programmers to enjoy the program. So I'm thrilled at the rapid evolution of MT, it's just that I, as one of those "average" users, don't want to get lost in the shuffle.
I'm all for the development of new features and the evolution of this program. What I'm not comfortable with is the seemingly increasingly separatist attitude that is making people like me feel like idiots for not being programmers. I'm starting to get the message that only the elite coders of the world will be able to use this program, and that people like me will be groveling at their feet for help on getting the functionality we want and have access to all of the goodies. I understand that in the development phase, that certain protocol must be followed for consistency, and that things will usually start out more complex to then be refined and streamlined for us "average" users.
What I don't care for is my personal sense that MT is turning into a 2 class program; where the elites get to use all of the goodies and us average users are stuck begging for scraps from the big table.
My ultimate hope is that once everyone agrees on the structure, that some effort will be made to make the program accessible to non-programmers who don't want to have to depend on programmers to enjoy the program. So I'm thrilled at the rapid evolution of MT, it's just that I, as one of those "average" users, don't want to get lost in the shuffle.
"Neither hexes nor squares can confine me!"
James Anthony
"It's all in your head....."
http://www.spelz.net
James Anthony
"It's all in your head....."
http://www.spelz.net
Let's look at it this way. What are the most common programming languages in use today? For Windows it's C++, C#, VB.NET, or Java. For Mac it's C++, Java, or objective C. For *NIX it's C, C++, or Java. For the web it's JavaScript, and server-side stuff based on Java, C#, PHP, or VB.NET.Big_Mac wrote:C#(C Sharp) is so far the only noted language that is Case sensitive.
(and before someone says it, I know there are plenty of others still in use on all of those platforms, I'm just covering the most common ones, according to my own experience)
If I counted right, that list contained 8 different languages. Of those 8, ONLY ONE is not case sensitive, that being VB.
If you want to start getting into the minor languages, I could probably name 2 case sensitive ones for every 1 named that isn't.
Now, having said that, do I think that this is how MT macro syntax should be? Not really. I'd like to be able to choose to compare strings in a case sensitive or in-sensitive way, and I just want the variable name usage to be consistent, weather that be case sensitive or not.
- Full Bleed
- Demigod
- Posts: 4736
- Joined: Sun Feb 25, 2007 11:53 am
- Location: FL
Yeah, but X does not equal x.thelevitator wrote:I'm not a programmer, but I think I am one of the original 50 members of this forum. I've been using this program since at least 1.1, maybe even before. I have to say that I'm a bit wary of how MT has been evolving over the last 6 months. It feels like the program is starting to be developed on the assumption that people have to be programmers to enjoy the full features of the program. It's starting to make this long-time user and idea contributor feel pretty left out.
I'm all for the development of new features and the evolution of this program. What I'm not comfortable with is the seemingly increasingly separatist attitude that is making people like me feel like idiots for not being programmers. I'm starting to get the message that only the elite coders of the world will be able to use this program, and that people like me will be groveling at their feet for help on getting the functionality we want and have access to all of the goodies. I understand that in the development phase, that certain protocol must be followed for consistency, and that things will usually start out more complex to then be refined and streamlined for us "average" users.
What I don't care for is my personal sense that MT is turning into a 2 class program; where the elites get to use all of the goodies and us average users are stuck begging for scraps from the big table.
My ultimate hope is that once everyone agrees on the structure, that some effort will be made to make the program accessible to non-programmers who don't want to have to depend on programmers to enjoy the program. So I'm thrilled at the rapid evolution of MT, it's just that I, as one of those "average" users, don't want to get lost in the shuffle.