SRL Archive - Development

Right now most methods are named the same as SCAR named them.. This is quite handy for most of us, since we will directly know what function we are looking for..

However, I find that some methods are named badly in SCAR.. For example all the Bitmap routines. There is not consistency in where the word 'Bitmap' is placed:
CreateBitmapFromText
LoadBitmap
BitmapFromString

But if you look at all the 'Loading' functions, there is some consistency -> LoadBitmap, LoadDTM etc..

Now I'm not quite sure what to do, in my opinion we should make a proper naming set. However that will force us to 'learn' these new names.

Any suggestions whatsoever on this subject, please post them.

Also; I'm thinking about exporting the whole bitmap class.. That should make life a lot easier for us, OOP lovers!

People can relearn it and it will make life a lot nicer and easier once they have. Same goes for OOP :)

Can we name them both and try to phase out the old names? :)

And yes, OOPness would be really nice with bitmaps and such (DTM.AddPoint, etc)

From: Widget
Can we name them both and try to phase out the old names? :)

And yes, OOPness would be really nice with bitmaps and such (DTM.AddPoint, etc)

I like the idea of having both in the beginning and maybe if it's possible some kind of message that the method is deprecated when people use it?

What would be the way to go then?
Something like:

bmpLoad
bmpFromString
bmpFromText

I think it should be Action-Type-Where-Modifier

LoadBmpFromFile
FindDTMTolerance
GetUptext

Although I guess that's mainly how SCAR does it anyway

From: Widget
I think it should be Action-Type-Where-Modifier

LoadBmpFromFile
FindDTMTolerance
GetUptext

Although I guess that's mainly how SCAR does it anyway

So you rather bundle the actions, instead of the objects?

EDIT: BitmapFromString doesn't have an "Action" name..

Create?

Well, I don't care how we name it.. As long as it's consequent and clear for the scripter.

I like the class OOP approach.

Bitmap.createFromText();
DTM.Find();
DTM.FindMulti();

LoadBitmapFromString would be the name then if we follow Widget's convention.

Oh and I'm against OOP until we can use it in our scripts (aka, until we dish pascalscript).

From: Markus
LoadBitmapFromString would be the name then if we follow Widget's convention.

Oh and I'm against OOP until we can use it in our scripts (aka, until we dish pascalscript).

We can use OOP in our scripts :confused:
We just cannot 'create' OOP in our scripts.

I would prefer an OOP approach to the main sections, ie DTM's and bitmaps, otherwise it should start with the item then the action, ie BitmapLoad rather than LoadBitmap otherwise if you're looking for a bitmap specific function (such as when doing ctrl + space) you would have like 20 other pointless functions when you just want the one that refers to bitmaps.

From: mixster
I would prefer an OOP approach to the main sections, ie DTM's and bitmaps, otherwise it should start with the item then the action, ie BitmapLoad rather than LoadBitmap otherwise if you're looking for a bitmap specific function (such as when doing ctrl + space) you would have like 20 other pointless functions when you just want the one that refers to bitmaps.

That's exactly what I thought..

Right now the bitmap methods; LoadBitmap etc.. are completely compatible with the TMufasaBitmap exported class. I mean you can exchange from Int to the corresponding TMufasaBitmap and visa versa.

The names aren't supposed to contain Bitmap in the same place, they're supposed to be a clause. There's a difference.

I would say the only things, however, that deserve promotion to OOPness are DTMs and Bitmaps. Because they're objects, and you operate on them. That really isn't a necessity, though, but fairly annoying until you can create classes in PascalScript.

Well to be honest.. When I want to Create a bitmap from text, the only thing I know for sure about the method that does it, is that it 'contains' the word 'Bitmap'. In scar I would have to open manual, ctrl +f -> bitmap, and search all the results to find the correct method name.. While if all the bitmap methods would start with Bitmap, I could just ctrl + space, bitmap and quickly look through the list. But that might just be me.

From: mastaraymond
Well to be honest.. When I want to Create a bitmap from text, the only thing I know for sure about the method that does it, is that it 'contains' the word 'Bitmap'. In scar I would have to open manual, ctrl +f -> bitmap, and search all the results to find the correct method name.. While if all the bitmap methods would start with Bitmap, I could just ctrl + space, bitmap and quickly look through the list. But that might just be me.

It's me too - it reminds me of a guy talking about vim when he was saying that most people are familiar with certain things and so they think it makes logical sense when in fact it doesn't and Scar's naming scheme definitely has no logical sense at all. For example, try to find the method that deletes a line in the debug box - I'm pretty sure you would have to go through the manual.

Logical is completely subjective.

OBJECT + ACTION + MODIFIER + WHERE

^that :)

Regardless of how subjective, no logic explains Freddy's naming scheme - I'm fairly sure it was which ever name he came up with at the time while disregarding any previous methods of naming he had.

From: Nava2
OBJECT + ACTION + MODIFIER + WHERE

^that :)

I guess for now I'll add that ^, and make an option to export SCAR names?

I'm still thinking it's a bit silly to export Scar names though. I mean, scripts won't work anyway and if they wanted to make them work it would just be a bit of logical renaming. Seeing as SRL 5 will probably be released about the same time (an assumption) and all scripts will have to be rewritten for it, I think it wouldn't be of much use - especially if they were to just be removed later on.

From: mixster
I'm still thinking it's a bit silly to export Scar names though. I mean, scripts won't work anyway and if they wanted to make them work it would just be a bit of logical renaming. Seeing as SRL 5 will probably be released about the same time (an assumption) and all scripts will have to be rewritten for it, I think it wouldn't be of much use - especially if they were to just be removed later on.

You are correct to current plans

From: mixster
I'm still thinking it's a bit silly to export Scar names though. I mean, scripts won't work anyway and if they wanted to make them work it would just be a bit of logical renaming. Seeing as SRL 5 will probably be released about the same time (an assumption) and all scripts will have to be rewritten for it, I think it wouldn't be of much use - especially if they were to just be removed later on.

Exporting them would just mean a smoother change from Scar to Simba

Wouldn't exporting/aliasing mean SRL 4 along with most scripts would work almost out of the box with Simba?

From: Widget
Wouldn't exporting/aliasing mean SRL 4 along with most scripts would work almost out of the box with Simba?

Yes, that makes some sense.

I think there should be a 'Compatibility Mode', rather than having both available.

Only issue, what if we want to change parameter amounts etc.

From: Nava2
Yes, that makes some sense.

I think there should be a 'Compatibility Mode', rather than having both available.

Only issue, what if we want to change parameter amounts etc.

Well thats unavoidable, but for now most functions are the same, so that most of us can get started really quickly with simba.

Yeah, but we have the option to break the paradigm, we should really do so.

[/endsubtlebumptogetnewkidsontheblocksopiniononanimportantissue]

From: Method
I vote the new standard could be improved, then.

Perhaps someone should code a decent code hints system where a word typed in can match any part of a function name.

Looks like this might be the right place, then??

From: Method
Looks like this might be the right place, then??

Yes it is :)

Let's quickly settle this so we can continue the work.

I like the idea of either OOP or if that doesn't go through, start all methods with the object so you have the ability, for example, to type "bitmap" and see all bitmap related methods.

From: Bobarkinator
I like the idea of either OOP or if that doesn't go through, start all methods with the object so you have the ability, for example, to type "bitmap" and see all bitmap related methods.

+1. However: OOP > starting all methods with the same object.

Would improving the code hints system to match the user input anywhere in the word be too hard to do or should we do it so we can have our normal names back again?

From: Method
Would improving the code hints system to match the user input anywhere in the word be too hard to do or should we do it so we can have our normal names back again?

I just like consistency and the "normal names"(I'm assuming you're referring to the names in SCAR) seem very inconsistent to me.

From: Bobarkinator
I just like consistency and the "normal names"(I'm assuming you're referring to the names in SCAR) seem very inconsistent to me.

No, I'm referring to names that make sense, e.g.:

AddPostVariable instead of PostVariableAdd
OpenConnection instead of ConnectionOpen
FindBitmap instead of BitmapFind

Things like that are what I'm talking about. I'd like to have names that make sense over names that all start with the same word and are more awkward to type.

I see pros and cons of each, but honestly that awkwardness doesn't bother me, but I can't speak for everybody.

I personally like functions/procedures to all start with what they are doing, example: FindBitmap, FindDTM, etc. If the new way is better/easier then I'd say use that, getting use to the new names wouldn't be that hard.

~Camo

1st FindBitmap with codehints searching anywhere in the word.
2nd BitmapFind with codehints only searching from the beginning.
3rd FindBitmap with codehints only searching from the beginning.

From: Boreas
1st FindBitmap with codehints searching anywhere in the word.
2nd BitmapFind with codehints only searching from the beginning.
3rd FindBitmap with codehints only searching from the beginning.

Wat :redface:

Ever since I first read this thread I've been naming my procedures like MainFormIntialize instead of IntializeMainForm… It just makes a lot of sense imho :p

The Java like Method` of naming things beginning with a verb of some kind (ie add, get, find etc) is great when you have OOP code - you already know the object and so next you want to do something with it. If it isn't OOP though, then placing the objects name at the beginning makes it as close as it would be to OOP'y. That is my reasoning as to why I would prefer OOP, otherwise ObjectVerbEtc.

From: mixster
The Java like Method` of naming things beginning with a verb of some kind (ie add, get, find etc) is great when you have OOP code - you already know the object and so next you want to do something with it. If it isn't OOP though, then placing the objects name at the beginning makes it as close as it would be to OOP'y. That is my reasoning as to why I would prefer OOP, otherwise ObjectVerbEtc.

That's exactly what I'm trying to tell :p. All the bitmap functions are just wrappers around a Bitmap class, so to make the OOP-feel complete put 'Bitmap' at the beginning of these words :).

Or export it as a class and give it a real OOP feel :)

From: mixster
Or export it as a class and give it a real OOP feel :)

The bitmap class is already exported, I just haven't exported all its properties/methods yet.