Macro Best Practices

Discuss macro implementations, ask for macro help (to share your creations, see User Creations, probably either Campaign Frameworks or Drop-in Resources).

Moderators: dorpond, trevor, Azhrei, giliath, jay, Mr.Ice

User avatar
khabalox
Cave Troll
Posts: 35
Joined: Tue Jul 28, 2009 1:07 pm

Re: Macro Best Practices

Post by khabalox »

Azhrei wrote:
khabalox wrote:Even if they are defining functions of the same name on different tokens?
Why would you want to do that?
I'm not sure that one would. It looks like I misunderstood biodude, or at least took his idea to an illogical conclusion.
biodude wrote:This shouldn't be a problem if each lib: token is defining different functions in a way that is not dependent on other functions (running them can be dependent, but as long as you are just defining them, that's not a problem).
This is the key I was missing. For some reason, I was thinking .... well, I'm not quite sure what I was thinking.

Now that I think of it, it makes sense that I could have a Lib:Initiative token which has a bunch of macros related to initiative, some of which call the UDF getAbilityMod() which is written and defined on Lib:Functions. Even if I had UDFs on Lib:Initiative, I wouldn't need to "re"define getAbilityMod() there. *smacks forehead*

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Macro Best Practices

Post by Azhrei »

Beowulfe wrote:Is there any advantages or disadvantages of having multiple lib tokens?
Advantages: modularity, ease of reuse, ease of distribution.

Disadvantages: more tokens to keep track of, more tokens to import when starting a new campaign, pain to right-click and choose SaveAs if you've made a bunch of changes to a bunch of Lib: tokens.

User avatar
wyrmwood
Dragon
Posts: 458
Joined: Thu May 22, 2008 12:15 am

Re: Macro Best Practices

Post by wyrmwood »

Craig wrote:I just wanted to clear this up... pass by value seems to be a very misunderstood term, there is no speed difference between pass by reference/value (a lot of languages don't even have pass by reference, Java ... for example
OK, I apologize, I have to get a bit pedantic here... so, in Java, an object passes the reference by value - when I was in school, they taught this concept as "pass by reference" even though, since the reference is copied, technically, as you said, it's pass by value.

Here's the rub, you can manipulate an object that's passed in this manner (a copy of the reference) and still alter the data within the object... or you may not... depending on whether you manipulate what the object's actually pointing to (since those references are the same as in the original), or whether you manipulate the reference itself (since the reference is indeed a copy or pass by value).

This is not the same effect as how Java 'passes by value' a primitive data type, where no matter what you do, the original variable remains unchanged in the caller.

I might not be making sense, so here's a better explanation of the difference.

So, back to MapTool, why wouldn't pass by reference be "quicker" than pass by value if the reference is significantly smaller than the data it references? Or in the case of the question at hand, it appears that passing a single property is indeed more efficient than passing a large JSON, I'm assuming since it is passed by value? Or am I missing something?

EDIT: I was thinking about this and was wondering, if MapTool is like Java, that is, pass reference by value, then it still makes sense that a single value property is less overhead than a large JSON because each of the references pointed to by the JSON must be copied (even though the data itself is not). Thus if a JSON holds 5 property sized variables, it is still 5 times as much addressing information to send. Pass reference by value isn't going to be more efficient than passing (object) by value until you are working with enough data to make the addressing insignificant. If the object contained 10MB of data, then pass by reference (or pass reference by value) and pass by value would be dramatically different.

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: Macro Best Practices

Post by Craig »

wyrmwood wrote:
Craig wrote:I just wanted to clear this up... pass by value seems to be a very misunderstood term, there is no speed difference between pass by reference/value (a lot of languages don't even have pass by reference, Java ... for example
OK, I apologize, I have to get a bit pedantic here... so, in Java, an object passes the reference by value - when I was in school, they taught this concept as "pass by reference" even though, since the reference is copied, technically, as you said, it's pass by value.
I see your pedantic and raise it :)
They may have taught you this at school, but it doesn't make what they taught you right. It is pass by value, end of story. I cant stress the previous strongly enough, there is a clear unambiguous distinction between pass by reference and pass by value, its not a technically it is pass by value, it just is pass by value. I know a lot of people may have been taught otherwise, that is why I said its a very misunderstood term. I want to also address the "passes the reference by value" but I will leave that until a bit later in the post.
wyrmwood wrote:Here's the rub, you can manipulate an object that's passed in this manner (a copy of the reference) and still alter the data within the object... or you may not... depending on whether you manipulate what the object's actually pointing to (since those references are the same as in the original), or whether you manipulate the reference itself (since the reference is indeed a copy or pass by value).

This is not the same effect as how Java 'passes by value' a primitive data type, where no matter what you do, the original variable remains unchanged in the caller.
You are thinking about it the wrong way because it is exactly the same. It doesn't matter if it is a java object or primitive that is passed in, they are both pass by value and happen the same way. Since java always passes by value you can never alter the value that was passed in. Take the following example

Code: Select all

...

      v = new StringBuilder();
      v.append("This is a test");
      blah(v);
...

public void blah(Object o) {
    o = new String("Eh?");
}
After the call to blah(v), v still points to the originally allocated StringBuilder() object. This happens because "v" was passed by value, so you can never alter it in blah().

I know the next comment is going to be but I can change what is inside of the "v" string builder, and yes you can, but this is not changing "v" you are changing some of the contents of "v" and not "v" itself -- this is an important distinction, "v" is still exactly the same object as before the call, it just has a different state. Its like when you lend your car to a friend and they either throw out some of your empty fast food wrappers, or leave some of theirs in it, when you get it back its still the same car, you just have either more, less, or different things in it. Since primitive types have no contents you are not able to change their contents, this is why they appear to be passed different from objects where as in reality they are not. See the following

Code: Select all

....
    int a = 2;
    blah(a);
...

public void blah(int c) {
     c = 5;
}
The above code displays exactly the same type of behavior, I can assign to "c" exactly the same way I can assign to "o", and in both cases it will not affect "a" or "v" because both of these were passed by value not by reference. If pass by reference had occurred in either case then the values of "a" or "v" (or both) would have been modified.
wyrmwood wrote: I might not be making sense, so here's a better explanation of the difference.
I read that article, and I think its very poorly worded. It makes it seem as if something special is going on when you pass an object, i.e. Java takes a reference of that object and passes the value of that reference. This is not what is happening at all, and its one of the reasons the term "passes the reference by value" can be kind of misleading.

Take the following

Code: Select all

   o.someMethod();
So you usually think of this as "call someMethod() on object o", I am pretty sure that people don't usually think of it as "call someMethod() on object referenced by o", which is what is actually happening. So why would you take the following

Code: Select all

   blah(o);
And say "pass the value of the reference to object o". By adding the word "reference" in there and not doing the same to any object access people tend to infer that there is another level of indirection occurring when an object is an argument to a method. This is not the case though, all object access is via a reference to that object.

Or more simply put, all parameters are passed by value, when you pass an object nothing special happens compared to when you pass a primitive, the fact that you can do different things to them within the method is solely down to the fact that they are different and not because any thing different happens during the parameter passing.
wyrmwood wrote: So, back to MapTool, why wouldn't pass by reference be "quicker" than pass by value if the reference is significantly smaller than the data it references?
I think the problem is the following
wyrmwood wrote: when I was in school, they taught this concept as "pass by reference" even though, since the reference is copied, technically, as you said, it's pass by value.
From the above it appears that you have been taught incorrectly what pass by value vs pass by reference really means. So when I use the term "pass by value" you are assuming I mean "place a deep copy on the stack" which I definitely don't mean, and that certainly is not what pass by value means.
wyrmwood wrote: Or in the case of the question at hand, it appears that passing a single property is indeed more efficient than passing a large JSON, I'm assuming since it is passed by value? Or am I missing something?
In another thread about efficiency I detailed the difference of JSON vs String List/Properties vs Token properties. Accessing token properties is always a lot faster than JSON objects. Also when using user defined functions you will get a slow down when using JSON variables with a lot of data in them, this has nothing to do with pass by value vs pass by reference. The problem is the way the way the MapTool interpreter works, as it was designed only to run commands without any looping or flow control it grabs a line and parses it. If there is a loop then it parses the same lines in the loop over and over instead of just parsing it once into intermediate code and looping over that. User defined functions need to be expanded into [macro():] calls, and this requires a translation of the JSON object to a string (and then the first time you use it as a JSON object in the called macro it needs to translate it back into JSON) its this translation you are taking a hit on.

For those that want more technical details of how the macro script does things you can keep reading for those that don't then you can skip the rest of the post :)

First off there are two kind of unusual things about MapTool macro script
  • All values are immutable
  • There is no stack
All variables are stored in a Java Map, for all intents and purposes you can think of these as Heap memory. When a macro is called and a new scope is required for that macro a new Java Map is created -- since there is no Stack you can't support local variables by just altering the top of the stack. The passed arguments are also created in the new Heap because there is no stack.

So if you have the following

Code: Select all

[macro("blah@Lib:token"): someVar]
The the java code essentially does the following steps
  • Get the "someVar" variable from the current Heap (Java Map)
  • Assign the "someVar" to the macro.args variable in the new Heap (Java Map)
Although the code isn't exactly the following line, it is close enough

Code: Select all

newScope.put("macro.args", currentScope.get(argName));
Which is about as efficient as it is going to get and pass by value -- if you were to actually try to implement this as pass by reference it would be a little less efficient as you need add a way to support indirection.

User avatar
wyrmwood
Dragon
Posts: 458
Joined: Thu May 22, 2008 12:15 am

Re: Macro Best Practices

Post by wyrmwood »

Craig wrote: It makes it seem as if something special is going on when you pass an object, i.e. Java takes a reference of that object and passes the value of that reference.
I'm not sure what you mean... the article says "Java passes the references by value just like any other parameter. This means the references passed to the method are actually copies of the original references."
Craig wrote:This is not what is happening at all, and its one of the reasons the term "passes the reference by value" can be kind of misleading.
It's exactly what is happening :) and, it's "misleading" on purpose - something "special" is happening, that is, it is leading you away from what earlier languages call the "two" behaviors. Passing an object by value in C++ for example is indeed a "deep copy" (I like that term :)) and pass by reference affects the original object variable (like a swap or reassignment to a new object)... However, in Java, passing an object argument does not do a "deep copy" (why I don't like calling it pass by value) and yet can affect the original object's data, but not the object reference itself (a swap ain't gonna work, as explained, albeit perhaps poorly, in the article I referenced)... again, distinctly different from C++ pass by reference, so I (and others) use the term "pass reference by value". Tada!

If you never use other languages, you simply need to understand how Java passes arguments and you can call it what you want :) If you use other languages that have a distinctively different behavior, and you use the same terminology (previously defined...), and don't understand that distinction, you'll end up with code that doesn't do what you intended :)

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Macro Best Practices

Post by Azhrei »

wyrmwood wrote:Passing an object by value in C++ for example is indeed a "deep copy" (I like that term :))
Sorry, it's not a deep copy.

A deep copy is when an object contains pointers and the new copy doesn't copy the pointers but allocates new objects and assigns the pointers the addresses of the new objects. Then if those new objects also have pointers, the same process happens again.

C++ does not do that. If you have an object which contains an int and a char*, the value of those two is copied, which means the original object and the new object both have the same value in the pointer. If the new pointer is used in a call to delete (or free(), as appropriate), the data in the original object is now invalid.

The only time a pass by value is a deep copy is if the copy constructor for the object specifically copies all pointers within the object as objects themselves.
again, distinctly different from C++ pass by reference, so I (and others) use the term "pass reference by value". Tada!
And the reference data type in C++ is different from pass by reference. For the C++ reference data type, the calling function puts the address of the object on the stack and the compiler manipulates the function prologue in the called function so that references to the variable name are automatically dereferenced when accessed.
If you never use other languages, you simply need to understand how Java passes arguments and you can call it what you want :)
I understand what you're trying to say, but Craig's terminology is the one accepted within the IT industry as a whole. Some languages may tweak that terminology, but that doesn't change the basic definitions.

User avatar
wyrmwood
Dragon
Posts: 458
Joined: Thu May 22, 2008 12:15 am

Re: Macro Best Practices

Post by wyrmwood »

Azhrei wrote:
wyrmwood wrote:Passing an object by value in C++ for example is indeed a "deep copy" (I like that term :))
Sorry, it's not a deep copy.
:oops: Point taken. If you don't have a copy constructor... you are correct, any contained objects have to be re-allocated in the copy constructor. But, in practice, if you were passing by value, you'd create a copy constructor.

Irregardless, this is still distinctly different in either case (with our without the copy constructor) than what happens in Java...
And the reference For the C++ reference data type, the calling function puts the address of the object on the stack
Exactly
I understand what you're trying to say, but Craig's terminology is the one accepted within the IT industry as a whole. Some languages may tweak that terminology, but that doesn't change the basic definitions.
I wasn't aware the IT industry set terminology for computer science terms :mrgreen:

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Macro Best Practices

Post by Azhrei »

wyrmwood wrote:I wasn't aware the IT industry set terminology for computer science terms :mrgreen:
So you missed that memo, too? Man, we gotta get you caught up here! 8) ;)

Btw, there is no such word as irregardless. (Insert big grin here. :D)


(As an aside, this sentence comes from the pass by reference link I provided above:
wikipedia wrote:Some languages straddle both worlds; for example, Java is a call-by-value language, but since the results of most Java expressions are references to anonymous objects, it frequently displays call-by-reference semantics without the need for any explicit reference syntax.
Not super important since I think we understand each other on this anyway...)

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: Macro Best Practices

Post by Craig »

Ok I there are several misconceptions happening here that I will try to clear up -- I apologize if this post sounds harsh its not my intention, but I am trying to get directly to the point(s) and subtlety is not one of my stronger points :).

First off, java is strictly pass by value, never anything else. Nothing "special" ever happens to support this, its exactly the same as C for example.

From a computer science point of view
a) Pass by value - The expression is evaluated and the value of that expression is passed to the method/function. If the expression is a reference then the value of that reference is passed -- this does not make it pass reference by value, its still pass by value. The consequence of this is in a pass by value assigning a new value to the parameter will never change what the original variable is refering to in the calling function.

b) Pass by reference - A reference -- or alias if you prefer -- is created to what ever you are passing, and that reference is passed to the method/function, when ever you refer to that inside the method/function a "invisible" de-reference -- or alias evaluation-- will occur -- excluding when it is the target of assignment. The consequence of this is you can always assign a value to the pass by reference parameter and it will change the value of the variable in the calling method (after all this is the purpose of pass by reference).

Java always passes by value. You can easily test this, pass in an object and assign a new value to it (see my above posts) you will see that after you return it has not affected the variable at all. Since you can't assign a new value to the object it can't be pass by reference.
wyrmwood wrote: It's exactly what is happening :) and, it's "misleading" on purpose - something "special" is happening,
Ok this is wrong, java passes by value exactly the same way C passes by value. Nothing special is done when an object is passed. If you you believe this is happening its because you do not understand the Java memory model and the "." operator properly. All objects in Java are object references, you never deal with an object directly you always deal with its reference and "." always de-references whatever is to the left of it.

Think of "." as similar to the C "->" operator. When I use "->" within a function I can change what is inside a structure, but assigning a new value to the variable its self will not modify the variable outside the function. When I use "." inside a method within java I can change what is inside the object but assigning a new value to the object will not affect the variable outside of the method.

Pass by value has never meant that you can not de-reference the value and apply changes to the de-referenced value. Which you seem to be implying it does.

wyrmwood wrote: that is, it is leading you away from what earlier languages call the "two" behaviors. Passing an object by value in C++ for example is indeed a "deep copy" (I like that term :)) and pass by reference affects the original object variable (like a swap or reassignment to a new object)... However, in Java, passing an object argument does not do a "deep copy" (why I don't like calling it pass by value) and yet can affect the original object's data, but not the object reference itself (a swap ain't gonna work, as explained, albeit perhaps poorly, in the article I referenced)... again, distinctly different from C++ pass by reference, so I (and others) use the term "pass reference by value". Tada!
This is incorrect, passing an object in java is the same as passing a pointer in C or C++, that is because that is what is happening. You wouldn't say -- or at least you would be wrong if you did -- say that C is pass by reference because you can use -> to alter the values within a structure that is being pointed to. Its exactly the same for java you use ".' to alter the values within an object.

See this is where you misunderstand what is going on. Pass by value does not mean you cant use operators on a value that change its internal state. There is nothing special going on here at all. From the above I can see you don't understand the memory model of java or exactly what the "." operator means. Pass by value also doesn't mean I copy the internal value of the object to pass. Pass by value means you pass the value of the expression, in this case the argument happens to be a reference that does not conjure up some special third case of "pass reference by value" its still pass by value, just like C is pass by value and does not have some special third case of "pass pointer by value". Both languages only have pass by value.


Think of it this way

Java

Code: Select all

    Car smallCar ;
Is the same as the following C++ code

Code: Select all

    Car* smallCar;
and Java

Code: Select all

    smallCar.setName("Smart Car");
Is the same as the following C++ code

Code: Select all

    smallCar->setName("Smart Car");
In java

Code: Select all

    garage.park(smallCar);
is the same as

Code: Select all

    garage->park(smallCar);
Both are strictly pass by value and absolutely nothing special is happening in either case.
wyrmwood wrote: If you never use other languages, you simply need to understand how Java passes arguments and you can call it what you want :) If you use other languages that have a distinctively different behavior, and you use the same terminology (previously defined...), and don't understand that distinction, you'll end up with code that doesn't do what you intended :)
I have used many other languages. I understand how java passes arguments. I understand the terminology. From the above posts you do not. You are saying there is something special going on where a reference is created to the object and passed by value. This is not the case, because creating a reference and passing the value is "pass by reference" which means I could assign a value to that and it would modify the variable of the caller.

Examples of pass by reference are in out variables in pascal and ada. Where you can assign a new value to the variable that is passed in (not just modify its state) and that changes the value of the variable from the caller.

Java is always strictly pass by value, there is nothing special going on with objects what so ever. To say that there is mean you misunderstand what pass by value means, the java memory model, what the "." operator is doing, what the new operator is doing or a combination of them. Since you don't understand what is happening you think that something special is happening during object parameter passing but it is not. The java world post does not disagree with this what I have said as I said earlier its just worded badly.

Have a look at http://java.sun.com/docs/books/jls/thir ... html#8.4.1 the java language specification spells out the passing semantics are pass by value. If the JVM is implemented as per the specifications -- and we all hope that they are -- it can not be anything other than pass by value.


edited for typos

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Macro Best Practices

Post by Azhrei »

While I agree with you 100% Craig, be aware that the wiki article I linked to previously admits that the water turns a bit gray because some languages use strange nomenclature. For example, the wiki article mentions call by sharing which is actually a better description for Java's implementation, while pass by value better describes the Java semantics...

Interesting stuff, though. It made me look things up in wikipedia and I learned a few phrases that I hadn't heard of before (like call by sharing).

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: Macro Best Practices

Post by Craig »

Azhrei wrote:While I agree with you 100% Craig, be aware that the wiki article I linked to previously admits that the water turns a bit gray because some languages use strange nomenclature. For example, the wiki article mentions call by sharing which is actually a better description for Java's implementation, while pass by value better describes the Java semantics...
Alrighty then! I always said its not a proper "geek throw down" unless someone has to show Wikipedia is inaccurate ;)

From the wikipedia article
Also known as "call by object" or "call by object-sharing" is an evaluation strategy first named by Barbara Liskov et al. for the language CLU in 1974[1]. It is used by languages such as Python[2], Iota, Java (for object references)[3], Ruby, Scheme, OCaml, and many other languages. However, the term "call by sharing" is not in common use; the terminology is inconsistent across different sources. For example, in the Java community, they say that Java is pass-by-value...
The article says that java community says java is pass by value -- and for good reason because it is-- yet says that call by sharing is what is actually done without providing a single reason why this is the case. If you follow the reference [3] to http://www.cs.cornell.edu/courses/cs412 ... /iota.html which is actually a set of lab or lecture notes for a language called Iota. The sole backing of the assumption that Java is call by sharing comes from the following statement.
As in Java, the calling semantics are call-by-sharing: the formal argument variable and the actual argument share the same value, at least until the argument variable is assigned to. Assignments to the argument variable do not affect the value passed; however, if the value passed was an array, assignments to elements of that array will be visible from the calling context as well, since it shares the same array object.
This statement contains no references and is based on anecdotal evidence that is also equally as valid for pass by value. In fact if you you examine the sentence more carefully you will see it does not really exclusively describe call-by-sharing, look at the this sentence "the formal argument variable and the actual argument share the same value, at least until the argument variable is assigned to. ", this is the exact behavior of pass by value variables, two variables share the same value. Call-by-sharing would imply some sort of copy on write variable reference.

However if you examine the JVM specification http://java.sun.com/docs/books/jls/thir ... html#8.4.1
When the method or constructor is invoked (§15.12), the values of the actual argument expressions initialize newly created parameter variables, each of the declared Type, before execution of the body of the method or constructor. The Identifier that appears in the DeclaratorId may be used as a simple name in the body of the method or constructor to refer to the formal parameter.
The key part here is "When the method or constructor is invoked (§15.12), the values of the actual argument expressions initialize newly created parameter variables." So new variables are created, and they are initialized with the result of the expression in the argument list to the call, this my friends is a text book definition of pass by value. no sharing occurs, all variables are new.

Take the following

Code: Select all

   Object o = new HashMap();
   int v = 10;

   this.someMethod(1, v, o);
This is what happens
  • The first argument is evaluated (1 evaluates to 1) the value of this copied to a new variable
  • v is evaluated and in this case evaluates to 10, the value of this is copied to a new variable
  • o is evaluated and evaluates to (o is already a reference) and the value of this copied to a new variable.
Primitive values, primitive variables, and object variables are treated exactly the same.

The treatment of "o" is nothing special in the above case, take the following

Code: Select all

    Object o2 = o;
In the above "o" is evaluated and returns "o" (again its already a reference).

The same for

Code: Select all

    o.foo()
In the above case o again evaluates to an object reference (see Java in a Nutshell for object member access)

Not too surprisingly the Java certification material agrees with the JVM spec
http://books.google.com.au/books?id=pER ... ue&f=false

Or from yet another source
From 2.6 of The Java Programing Language, Fourth Edition (Ken Arnold; James Gosling; David Holmes)
Some people will say incorrectly that objects are passed "by reference." In programming language design, the term pass by reference properly means that when an argument is passed to a function, the invoked function gets a reference to the original value, not a copy of its value. If the function modifies its parameter, the value in the calling code will be changed because the argument and parameter use the same slot in memory. If the Java programming language actually had pass-by-reference parameters, there would be a way to declare halveIt so that the above code would modify the value of one, or so that commonName could change the variable sirius to null. This is not possible. The Java programming language does not pass objects by reference; it passes object references by value. Because two copies of the same reference refer to the same actual object, changes made through one reference variable are visible through the other. There is exactly one parameter passing mode—pass by value—and that helps keep things simple.

User avatar
RPTroll
TheBard
Posts: 3159
Joined: Tue Mar 21, 2006 7:26 pm
Location: Austin, Tx
Contact:

Re: Macro Best Practices

Post by RPTroll »

My brain hurts.
ImageImage ImageImageImageImage
Support RPTools by shopping
Image
Image

User avatar
wyrmwood
Dragon
Posts: 458
Joined: Thu May 22, 2008 12:15 am

Re: Macro Best Practices

Post by wyrmwood »

RPTroll wrote:My brain hurts.
mine too :)
Craig wrote:...
OK, I concur, Java passes by value. Java passes primitives by value and passes object references by value. (Wait, isn't that what I said to begin with?)

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: Macro Best Practices

Post by Craig »

wyrmwood wrote:
RPTroll wrote:My brain hurts.
mine too :)
Craig wrote:...
OK, I concur, Java passes by value. Java passes primitives by value and passes object references by value. (Wait, isn't that what I said to begin with?)
Well you did say something special is going on to create the reference that is different from primitives so its was only "technically" pass by value :) Which is the bit that was incorrect.

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: Macro Best Practices

Post by Rumble »

The upshot of all of this being: macros can go real slow if you use excessive JSONs. :P

Post Reply

Return to “Macros”