I’ve heard looking up the Session can be an expensive call.
Does doing:
dim Session as Session = Sessionhelp a lot with this?
Is it really worth it?
Don’t use that style - really.
It will cause you problems in some useful circumstances where the type OR instance name could be valid (like a cast) where the compiler literally cannot tell if you mean the instance name OR the type name.
I’ve run into this particular idiom and corrected it to avoid that problem.
At least do
dim thisSession as Session = SessionCan holding a reference save you time - certainly.
But I’d profile how often you use it etc before doing it so you have a benchmark of how much time it might save you.
Any way Xojo could “cache” the session value to the thread once its looked up so if you call session again in the method it would pass the cached version instead of trying to look it up again? Kind of like a lazy computed property.
Yes
You add a property to the thread, set it and use that 
Then you can have your code use the value you stuffed in that cache
No “magic” required
I didn’t mean my thread. I meant Xojo’s session thread processing the callback for the client’s event.
It would also be especially helpful for debugging if this was always a property when we break without us having to add it to every single method call.
Lets put it this way
a) I’m not the web framework expert so I don’t know BUT
b) IF it could have been done accurately it probably already would have been
Before we go down a complicated path, have you actually measured the amount of time this call takes?
I assumed that the amount of time it takes would be related to the number of sessions that exist but I suppose if its a hashed lookup like a dictionary then it might be negligible.
I was mostly concerned with having to add this to every single method call. It’s annoying when the code breaks and I have no way of jumping through the session object unless there’s explicitly a session object declared in the block of code I’m in. Even if it was only in debug, it would be nice if it just added an invisible dim debugSession as session = session to the top of every block - or just have the debugger somehow add or show this by any means. You also can’t click on the App object and loop through sessions in the debugger because it’s only really an array through method calls and not an actual object array. Might have something to do with the fact that a “computed array” concept doesn’t really exist in Xojo. Might also be helpful if the debugger had something to identify objects that implement the IEnumerable interface. (?)
Well okay, let’s look at it from the other direction. Let’s say there is noticeable overhead to retrieve the session (I’m not near my computer, so this is pure hypothesis). If we added a call to get the session to every method, we could significantly slow down your app, and for all of the people who don’t care about the session being there, that hit might be unacceptable.
That’s why I said only for Debug and certainly a checkbox for on/off similar to controlling break on exceptions. Or would it be possible to have it only retrieve/add the session property when it hits a break?