ID:132676
 
(http://www.byond.com/docs/notes/462.html)
Only one word: why?

...Also, that page says "A view text procs".
Seems fine to me. Some deprecation to give notice a few versions earlier would've been a good way to go too though. The language needs to evolve, and refactoring is a part of that.

edit: Oh I see, you have basically deprecated the old ones. Fair play, carry on.
Kaioken wrote:
Only one word: why?

I was wondering that too. It's a bit of a pain in the ass.
Kaioken wrote:
(http://www.byond.com/docs/notes/462.html)
Only one word: why?

Because the old notation was idiotic. It also caused problems in reference urls since case is ignored in a lot of places.

<small>...Also, that page says "A view text procs".</small>

Oops, thanks.
In response to Tom
Tom wrote:
Because the old notation was idiotic.

Always seemed just fine to me. But why make all old code need to be modified so that it doesn't cause warnings? That's just a pain, as you also need to do it with libraries and the like.

It also caused problems in reference urls since case sensitivity is ignored by the webserver.

So this is the real reason? But surely you could have worked around that.
In response to Kaioken
Kaioken wrote:
Tom wrote:
Because the old notation was idiotic.

Always seemed just fine to me. But why make all old code need to be modified so that it doesn't cause warnings? That's just a pain, as you also need to do it with libraries and the like.

Because it is very easy to accidentally type "cmpText" instead of "cmptext" and the user should be alerted that they are different procs. Also, we can't distinguish between old code and new.

It also caused problems in reference urls since case sensitivity is ignored by the webserver.

So this is the real reason? But surely you could have worked around that.

No, the real reason is that the old notation was idiotic. The fact that it caused problems when building the new reference urls was a convenient excuse to finally change it.

I'm sure you'll survive.
In response to Tom
Tom wrote:
I'm sure you'll survive.

Easier said than done.

BlahblahEx is the way M$ does some of their 2nd versions of Win API functions. We aren't allying ourselves with the Empire now, are we?

I think we can all just cast a "protection from case sensitivity" and be fine. We just need to get some more of our programmers up a few more levels so they can cast 3rd level codes.
In response to Tom
Tom wrote:
Also, we can't distinguish between old code and new.

Actually it occurred to me that we could use the modification date to do this, so I added a little patch. Now, as long as you don't edit old code (eg, libraries), you won't get the warning. And you should update newer code so that's consistent.

We had to re-release v.462 due to another bug, so the updated 462.1056 (with this fix) is available at the download page.
In response to Loduwijk
Loduwijk wrote:
BlahblahEx is the way M$ does some of their 2nd versions of Win API functions. We aren't allying ourselves with the Empire now, are we?

Trust me, if you saw some of Tom's comments in the code you'd know that was never going to happen. :)

Basically the reason for it was to come up with a consistent naming convention. My original thought was findTextExact(), etc. and cKeyWithCase(), but Tom pointed out it made way more sense to just use the lowercase name plus Ex for all four of the changed procs. I like his notation much, much better.

I think we can all just cast a "protection from case sensitivity" and be fine. We just need to get some more of our programmers up a few more levels so they can cast 3rd level codes.

We actually had a bug report related to this, which spurred interest in improving the reference. The #ckey and #cKey anchors in the reference were causing people grief when they used Internet Explorer, which doesn't distinguish between the cases; frankly I'm amazed no one mentioned it years ago.

So there were good reasons to deprecate the old names. This was actually something that was kind of overdue.

Lummox JR
In response to Kaioken
Is ctrl+H so hard to use?
In response to Airjoe
Airjoe wrote:
Is ctrl+H so hard to use?

Exactly what I was thinking. I quite like the "Replace in all files" option it gives. Seems nice.
In response to Tom
If you're going to go around renaming procs (as well as for new ones) do you think you could pick a single competent naming standard and stick with it?
mouse_pointer_icon :underscores
Move :single capitalization
OpenPort :upper camel casing
cKey/ckeyEx :lower camel case
fexists :none?

It seems like you've used just about every naming convention available, without any type of consistency. Just whatever you were working on one day fell into a specific method, and then next day was a new one.
It makes it pointlessly more difficult to memorize things, and imparts incredibly poor standards onto new/learning developers.
In response to Falacy
In response to DarkCampainger
DarkCampainger wrote:
http://www.byond.com/members/DreamMakers/ forum?id=729976&view=1

Not really sure how that relates, but OK.
In response to Falacy
Falacy wrote:
DarkCampainger wrote:
http://www.byond.com/members/DreamMakers/ forum?id=729976&view=1

Not really sure how that relates, but OK.

Garthor wrote:
There are already good naming conventions: lowercase for functions, UpperCase for methods. That is: any proc belonging to an object is in UpperCase, whereas any proc that is global is in lowercase. Functions also must use underscores to separate words, because they don't use case to indicate where a new one begins. The 2 for the conversion functions is a bit iffy but at least is consistent among them.

So...

mouse_pointer_icon // variables are all lowercase, and so need underscores to differentiate words
Move() // Method of an object, capitalize first letter of each word
OpenPort() // Method of an object (world), capitalize first letter of each word
cKey/ckeyEx // Special case
fexists() // Global function, lowercase. Unnecessary to force f_exists() as it's still readable.
In response to DarkCampainger
Ah I see. With the way I have my forum viewing setup your link just directed me to the first post in the topic, &single=1 would have sent me to that specific post.
However, I have to disagree with majority of Garthor's claims there. Everything except his assumption about object owned procs seems incorrect.
winget() vs get_step() just for one example. Or even the proc(s) that this very topic is about =P
In response to Falacy
Falacy wrote:
However, I have to disagree with majority of Garthor's claims there. Everything except his assumption about object owned procs seems incorrect.

What he said is correct. There have always been naming conventions in DM, though some miss them.

winget() vs get_step() just for one example.

Example of what? Of them fitting into the convention, perhaps? Being global procs they are both entirely lowercase, and when a separation between words is needed, an underscore is used. The separation of words goes only when deemed helpful, such as in the aforementioned case of fexists() not being f_exists().
Also, there are sub-conventions in procs of the same family. For example, all the procs that have to do with the interface are named "winsomething", all the value-conversion procs have a 2 in them to separate the input value type and the output value type ("text2path()"), all the text handling procs are named after what they do with "text" appended ("copytext()"), etc.

Or even the proc(s) that this very topic is about =P

Which have their own convention. All instructions that have to do with text have their case-sensitive versions' second word's first letter capitalized "(copyText()", "cKey()". Quite a clever and easy to remember and use convention, but now this has been changed to a trailing "Ex" instead, despite everyone and their mother being already used to the previous convention. At least Tom changed it so you won't have to go into older projects (like used libraries) one-by-one and update them to get rid of the warnings.
In response to Kaioken
Kaioken wrote:
What he said is correct. There have always been naming conventions in DM, though some miss them.
winget() vs get_step() just for one example.
Example of what? Of them fitting into the convention, perhaps? Being global procs they are both entirely lowercase, and when a separation between words is needed, an underscore is used.

The fact that everything is lower case, separated by underscores, except for owned procs doesn't make much sense. Especially considering that global procs aren't, and for some reason follow variable naming which makes even less sense. Deciding when a _ is "needed" is more of a whim at the time of creation, and should always be inserted if possible ie: is_type(). The 2's are fine considering the rest of the proc is all lowercase (though I don't much care for the all lowercase to begin with) and (I don't see why everyone is making a big deal out of the 2s?). And the old findText was fine as well, it didn't follow the rest of the naming conventions, but then again the new way doesn't either; it did however clearly emphasize what the proc did.

Also, there are sub-conventions in procs of the same family. For example, all the procs that have to do with the interface are named "winsomething", all the value-conversion procs have a 2 in them to separate the input value type and the output value type ("text2path()"), all the text handling procs are named after what they do with "text" appended ("copytext()"), etc.

Which would be exactly what I'm talking about. They're not necessarily following an overall naming convention, simply one that they decided on when they were working on those specific systems.


EDITS:
Stephen001 wrote:
I don't really expect BYOND to support legacy libraries from dead or lazy maintainers.

Maybe you don't understand the point of a library?

BYOND's current legacy support rivals Microsoft's, even they dropped VB6 eventually.

As if those are comparable in the least o.O
In response to Kaioken
I don't really expect BYOND to support legacy libraries from dead or lazy maintainers. BYOND's current legacy support rivals Microsoft's, even they dropped VB6 eventually.
In response to Stephen001
Um... pretty much all of the well-known, useful and high quality BYOND libraries aren't updated regularly anymore (more often than not, there's no reason to update after initial bugs have been fixed and as such). If you don't support them, then you're essentially left with no libraries. =)
Page: 1 2