exported function and "by ref"

[Yukiko]

I am certain that somewhere in the 14 or so years I have been working with POL and programming in eScript that I have learned about the two items mentioned in my topic but for the life of me I can't remember the particulars about when to use them or why.

What causes the need to use an exported function definition?

Please explain what by ref means in a function definition and when is it appropriate or necessary to use it.

I must have known this but the memory circuits that held this data must have failed. Time for an upgrade of my Bio-Mem(R) implants.

[RusseL]

exported functions are hooks for already existing core functions (exported function replace or extend core function).
item method scripts, packet hooks etc., are using exported functions.

byref - its the same as reference/pointer in C/CPP.

Code: Select all

program blabla()
   var xx:=6;
   var yy:=6;

   usebyreftester(xx, yy);

   print("xx="+xx)
   print("yy="+yy)
endprogram

function usebyreftester(byref xx, yy)
   xx:=xx+10;
   yy:=yy+10;
endfunction

output will be
xx=16
yy=6



ps:
or i am wrong and you mean byref function blabla? never seen such syntax.

[Yukiko]

You're correct. I should have posted an example for byref but you knew what I was asking.

My problem is (Probably because of my limited experience, or more so my skill.) I can't think of a place where I would use byref.

As for exported function use, I'm not ready to tackle modifying or replacing core functions. Though at some point I'm probably going to have to get familiar with packet hooks. So far I have been lazy and just used working packet hooks I've found on the forums or in "complete worlds" I've acquired.

Thank you for the help.

[CWO]

ya all of the hooks are exported functions and mainly the only place I've ever used byref is the packet in the packethooks since it's required to be passed back to the core to be sent or received and your return value only states if it's being used or ignored by the core.

I feel byref in other places is just bad practice. Either make the variable global to the script or use return values to make things consistent and readable in the calling function.

[RusseL]

actually, byref must be used with most of average functions.
Otherwise every single function call Core will create a copy of your function parameters in memory, and then create again a copy of return value.

I think, nowadays noone use it because we have too much RAM

Example: both functions are doing the same, but second will use much more memory and instructions.

Code: Select all

program blabla()
  var xx:=10;
  var yy:=10;
  
  increment_byref(xx);
  yy:=increment_simple(yy);  // here yy will be duplicated and sent to a function
  
endprogram

function increment_byref(byref xx)
 xx:=xx+10;
endfunction

function increment_simple(yy)  
  yy:=yy+10;
  return yy;  // here yy will be duplicated again, cause yy from this function will be removed as garbage
endfunction

ps. This is how it works in C, but i think eScript will do the same.

[Turley]

Don't think about RAM usage due to missing byrefs instead consider the CPU overhead which you pay due to the copy operation.
A copy is not for free it takes time, of cause for small objects this is nothing measurable. But if you start to transfer structures this will be measurable.
In modern times the RAM usage is not a big deal, but you should check the size of your L1 and L2 cache and then think again about memory usage. (Can someone name these sizes without looking into his manual?)
For normal scripts this is nothing to take care about, only if you have to much spare time and got bored
But if you script e.g. a AI which runs for several thousand NPC you should consider this, or please never complain about high CPU usage and lags :p
Another pro tip would be to consider reducing memory usage of dictionaries and structs, due to the nature of the escript representation the struct member name is like a dictionary key a simple string. Thus script size increases with long key names.

[xeon]

I used byref a couple of times to be sure to have the reference to the objects and not a copy of the object.
Wait rereading what I wrote it's almost tautology. It must be the hour. Anyway.

[Yukiko]

Thanks for the replies and info.

Both Russel and Turley make good points and no Turley I don't know my L1 and L2 cache sizes from memory

Turley's admonition about processor cycles is something to be seriously considered.

Turley would you say one should use by ref for all complex variables i.e object references, structs, dictionaries etc. or only in scripts like AI (especially merchant.src because it literally runs on many NPCs) where they might be running multiple times?

[Turley]

Object references are not expensive to copy, as the name states it's a reference thus they also behave different from the primitive types. You don't get a second character in game by passing the script object into a function :p
Since it's just a reference copying this (pass by value) should be of the same speed/memory as creating a reference (pass byref).
For primitive types thats different each integer,double,string,array,struct,dict gets deepcopied for a function call.
For integer and doubles this shouldnt matter, but for the other types this can be expensive.
Thus you can decide if its worth it or not. I would say for stuff like commands this never has any effect since they are typically shortrunning and speed does not matter there. For controlscripts or AIs this can matter since they are the overhead you always pay during the execution of you shard.
The downside is that escript like most of the scriptlanguages has no way to mark a reference const, so you can by accident modify something you better should not. (that makes it a PRO tip )
The plus side is that its atleast transparent by the extra keyword "byref", for example python has an very complicated system with implicit reference effects, without any extra keyword.

[Yukiko]

The downside is that escript like most of the scriptlanguages has no way to mark a reference const, so you can by accident modify something you better should not. (that makes it a PRO tip )
The plus side is that its atleast transparent by the extra keyword "byref", for example python has an very complicated system with implicit reference effects, without any extra keyword.

Yes. I was thinking if I were to take your advice and convert to byref's in my control and AI scripts I would have to do a lot of checking to avoid changing things that the calling scripts assume would be left unchanged. And yes, I would call it a Pro tip.

eScript is a great language but as you say it has its limitations. I wish it had stronger type restrictions so when you declare a variable as a string it would only accept string assignments. I think that's the right wording. Some things could be implemented to tighten up the syntax etc. but it would probably break a lot of current scripts. The ancient UCSD Pascal system was constructed similar to POL where you had source files written in Pascal, which is a strict language, that were then compiled to pseudo-code and ran in a virtual machine or, what my son calls a container. That and its similarity in syntax to Pascal is what endears me to eScript and POL.