SRL Archive - SRL Suggestions

It seems like it would make sense to do something like this

type
  GolfClub = (Driver, Putter, Iron);

procedure SelectGolfClub(type: GolfClub);

rather than

//you can use the values of 'Driver', 'Putter', or 'Iron'
procedure SelectGolfClub(GolfClubType: string);

which is the way SRL does it.

using strings is bad because it allows for a lot of mistake. First, they could spell it incorrectly in the comment. Then they could spell it incorrectly when searching for it in the function. Then the user could spell it wrong. Along with it being annoying to have to put everything in 's.

The set would basically negate all the problems and if anything was incorrect, you would know it…since it would give you an error, rather than just not working, but still compiling.

I find is to be a good idea.

~RM

Yes, I hammered on using sets rather than strings/constants.

Is there any downsides? More CPU power needed? More RAM?
I would agree/disagree if I knew more about this

From: Zyt3x
Is there any downsides? More CPU power needed? More RAM?
I would agree/disagree if I knew more about this

Doesn't do much to the CPU.

It's a good idea as it shows up in the codehints in SCAR.

I was always curious about this. I think there's like ONE function in all of SRL that uses a set…

so, would you use it like:

type
  Golf = (fun, ok, boring);
  
procedure test(type: Golf);
begin
  case Golf of
    fun: writeln('fun');
    ok: writeln('ok');
    boring: writeln('boring');
  end;
end;

begin
  test(ok);
end.

?

There is another way to do this. Here is a procedure from the last SRLKara project showing it.

procedure Walk(FromLocation:(Seaman, KaraDock, Fishies, FallyBank); ToLocation:(Seaman, KaraDock, Fishies, FallyBank));
begin
  case FromLocation of
    Seaman :
      case ToLocation of
        KaraDock : SeamanToKaraDock;
        Fishies : Writeln('Invalid Request!');
      end;
    KaraDock :
      case ToLocation of
        Seaman : KaraDockToSeaman; //Needs to be done!
        Fishies : KaraDockToFishies;
      end;
    Fishies :
      case ToLocation of
        Seaman : Writeln('Invalid Request!');
        KaraDock : FishiesToKaraDock;
      end;
    FallyBank :
      case ToLocation of
        Seaman: FallyBankToSeaman;
      end;
  end;
end;

Thats even better, since its in the function, Unless people dont like that it makes the line really long.

Sets behave as constants AFAIK.

This being said, its also faster to do.

Do it, do it, do it!!

:wow:

Wow.. I'll update my script to use this :wowzers:

This isn't a set.. Besides, I think constants are way cooler :-D

You can also use the enumerations (single option) with sets (multiple options).

program New;
type
  a = (hey, there, you);
  b = set of a;
var
  x: a;
  z: b;
begin
  z := [hey, you];
  if (hey in z) then
    WriteLn('hey');
  if (there in z) then
    WriteLn('there');
  if (you in z) then
    WriteLn('you');
    
  WriteLn('');
  z := z + [there];
  
  if (hey in z) then
    WriteLn('hey');
  if (there in z) then
    WriteLn('there');
  if (you in z) then
    WriteLn('you');
    
  WriteLn('');
    
  x := there;
  WriteLn(Integer(x));
  x := hey;
  WriteLn(Integer(x));
end.

From: nielsie95
You can also use the enumerations (single option) with sets (multiple options).

program New;
type
  a = (hey, there, you);
  b = set of a;
var
  x: a;
  z: b;
begin
  z := [hey, you];
  if (hey in z) then
    WriteLn('hey');
  if (there in z) then
    WriteLn('there');
  if (you in z) then
    WriteLn('you');
    
  WriteLn('');
  z := z + [there];
  
  if (hey in z) then
    WriteLn('hey');
  if (there in z) then
    WriteLn('there');
  if (you in z) then
    WriteLn('you');
    
  WriteLn('');
    
  x := there;
  WriteLn(Integer(x));
  x := hey;
  WriteLn(Integer(x));
end.

Can do with constants as well, just requires some bitwise operations.. <– zeh leet way.

From: mastaraymond
Can do with constants as well, just requires some bitwise operations.. <– zeh leet way.

Constants will get a lot harder if you have a lot of options.

Um, as long as you know the first few numbers of n^x, it is pretty easy to do with constants and a var to store them?

const
  hey = 1;
  there = 2;
  sexy = 4;
var
  meow: Integer;
begin
  Writeln('meow = hey + there');
  meow := hey + there;
  if meow and hey = hey then
    Writeln('Hey');
  if meow and there = there then
    Writeln('There');
  if meow and sexy = sexy then
    Writeln('Sexy');

  Writeln('meow = hey + there + sexy');
  meow := meow + sexy;

  if meow and hey = hey then
    Writeln('Hey');
  if meow and there = there then
    Writeln('There');
  if meow and sexy = sexy then
    Writeln('Sexy');

  Writeln('Also, ');
  if meow and (hey + there) = (hey + there) then
    Writeln('Hey there!'); 
end.

Edit: Added just a little bit to the end

I said a lot of options ;)
Plus enums are easier to read/understand and more noob-proof.

From: nielsie95
I said a lot of options ;)

Theoretically you are right, but never seen that happen in SRL..

I don't think SRL will ever need 30 options and if they do, then Int64's can be drafted in for another 32 options!
If you wanted noob proof, it's very simple to turn it into a function

  function IsSet(the_set, the_val: Integer): Boolean;
begin
  Result := the_set and the_val = the_val;
end; 

:)

If you use sets, you should properly prefix them.

However, I believe enum often aren't the way to go - especially if you want to pass more options.

DoThis(dt_Run or dt_North or dt_East)

Could for example make a character Run towards North-East.

Constants of (Bitwise) numbers are the best, IMO.

You can just as easily pass multiple options with sets..

DoThis([dt_Run, dt_North, dt_East])

From: nielsie95
You can just as easily pass multiple options with sets..

DoThis([dt_Run, dt_North, dt_East])

Apart from the fact that you have to pass an array, rather than one integer. It's slower and not really standards compliant. Constants can also be shared among other languages, whereas this can be a serious problem with enums.
Passing the parameters like that seriously affects the complexity of the DoThis function, imo.

I don't think you pass an array… And let's face it, the time difference is so small you can ignore it. Actually, I calculated it for you, sets are 12 / 5000 ms or about 2,4 microseconds slower.

You're right about sharing with other languages, but for SRL sets are definitely a better option.

The only reason brought up so far that makes sets better is that they appear in codehints. Of course, well named const's that hold the relevant values would also appear.

Not to mention it would fit in better with the strong, Delphi influence of things such as those present in the whole form part. bsStyles and so on and so forth as examples.

From: nielsie95
I don't think you pass an array… And let's face it, the time difference is so small you can ignore it. Actually, I calculated it for you, sets are 12 / 5000 ms or about 2,4 microseconds slower.

You're right about sharing with other languages, but for SRL sets are definitely a better option.

No. I think it's better to learn everyone to code with proper standards.
Sets are obviously slower since you have to (worst case) iterate over all the items in the set. With bitwise this is still only one bitwise operation.

I personally think sets are only good for readability, but I'm sure they serve some other purpose…

I (also) personally think this is not good for SRL. Especially if they are named poorly.

Remember True and False in Mouse being swapped, because SKy introduced some weird type? It took me days to figure that out.

I just checked it. It seems like Delphi uses the bitwise method for sets, so there is still a limit. Only thing is, it uses the smallest Integer type (byte, word, integer) for storing.

I guess it's up to the scripter what he wants to use. I'd definitely use sets where possible, though. And I think sets/enums are better for SRL because of the easier debugging, it's a lot harder to pass wrong values with a set/enum.

Well, im glad that this at least has garnered support for not using strings anymore in SRL?

From: Dan Cardin
Well, im glad that this at least has garnered support for not using strings anymore in SRL?

Strings weren't supposed to be used any more, at all.
It was/is all bitwise constants. (You may no see this in SRL 4, but it is planned for future releases of SRL.)

How does a set make debugging easier, niels?

It's easier in the way that it is harder to pass wrong values. If I look at bitmaps.scar or tabs, I see that some people pass the constant value instead of the constant itself. If SRL updates, the constant value might have changed; causing the script to stop working. With enums, you force the scripter to enter the right thing.

From: nielsie95
It's easier in the way that it is harder to pass wrong values. If I look at bitmaps.scar or tabs, I see that some people pass the constant value instead of the constant itself. If SRL updates, the constant value might have changed; causing the script to stop working. With enums, you force the scripter to enter the right thing.

Well, if people are passing the constant value themselves it is entirely their own fault. I get your point, but I don't see the need, especially since it is just not pretty, IMO. It's not portable/parse-able, not easily generated, and allows less options than bitwise.

Its prettier than bitwise, faster to do (as in implimenting/writing) aswell.

Im not sure why it would need to be portable, and if it were needed to, then how it would not be so. I dont see how it allows for less options.

IMO the choices are more easily apparent, the result is more easily apparent, and its faster/less line-y to implement.