Roku Developer Program

[NewManLiving]

As a side note. If I have something like m.a.b.c in a loop or where I use it over a number of times I presently resolve it myself. l_var = m.a.b.c.

[TheEndless]

"RokuMarkn" wrote:
The latter. It's bad programming style, and avoiding globals is one of the reasons Object Oriented programming was invented. I discussed this previously here. Other than poor style and difficulty in maintaining the code, it's not going to break anything if you use globals.

--Mark

It may also be worth noting that using the global AA is the only way to implement global singletons...

[destruk]

If it truly is bad practice, bad programming style, evil, bad idea, etc etc then why do all these languages KEEP ALLOWING it to be used? Maybe if you feel so strongly about it, remove it in a future firmware update. Until then, there are mahy reasons why you would want to use global variables - one of which is not having to call a function with numerous values passed to it all the time, every time it is called. I find it's easier to leave things like server urls in the top of the script, as global, to reference throughout the rest of the program execution, rather than having to type out each server url over and over every time I need to get something from the internet. So thanks for leaving this 'bad practice' as an option.

[Komag]

I think having a few globals like server urls is not going to do any harm, but I can see the point that using a lot of variables that get changed and dynamically used throughout the whole program could make it harder to debug and keep track of things, as illustrated by RokuMarkn Here. I suppose it comes down to experience, preference, team policy if not working alone, etc.

[RokuMarkn]

There are situations where globals are appropriate, such as global constants or (in some cases) singletons like a Registry or FontRegistry. Experienced programmers already know that globals, like gotos, are dangerous. But in this forum there are readers with a wide range of experience, so it's hard to give guidance to inexperienced programmers without saying something that an experienced programmer, looking at a wider range of possibilities, may object to. But when a programmer with no experience with globals talks about moving all their data into globals, the appropriate response is "don't do that". Similarly if a new programmer recently discovered gotos and was considering replacing all his for loops with the more "powerful" goto, I'd say "bad idea". I did say globals should be used with caution, not that they should never be used. I've probably used at least one global in every BrightScript program I've written. I would still advise new programmers to mostly avoid globals, since they don't yet have the experience to see when they're being used inappropriately.

--Mark

[EnTerr]

"Komag" wrote:
Question - If I use "m" for "everything", it would create an additional layer for me, such as "m.cAA.mainMenu.w[1]" vs "cAA.mainMenu.w[1]". Everything would have this extra layer. Would that slow things down, since there is another dictionary lookup happening, or am I totally understanding that wrong?

You got it, the extra layer will slow things a bit. "Doting" is costly:

"EnTerr" wrote:
Luckily in B/S whatever comes naturally - laziness, do less typing - is also faster. Working with a local variable ("x") is an order of magnitude (> 10x) faster than "dotting" as m.x (regardless whether for global or object member). SImplifying a little bit here: m.x is just syntax sugar for m["x"]. Using global functions and local variables is fast, anything that involves a dot - not so much. Don't get all crazy on me now and banish object use completely. Optimize later, you may not need it.

[EnTerr]

"NewManLiving" wrote:
It would all depend on how the compiler resolves references. If it's a good compiler then it will resolve the reference at compile time. It would be nice to have an official word.

Yeah... no. There is no way for such references to be resolved in advance in dynamic languages like Lua or BrightScript, where X.Y is just a shortcut for X["Y"] and not a numeric offset inside a record. You don't know what's in `m` till you get to `m`.

"NewManLiving" wrote:
As a side note. If I have something like m.a.b.c in a loop or where I use it over a number of times I presently resolve it myself. l_var = m.a.b.c.

That's the way to do it, yep. Luckily here laziness in typing co-insides with efficiency.

[TheEndless]

"EnTerr" wrote:

"NewManLiving" wrote:
It would all depend on how the compiler resolves references. If it's a good compiler then it will resolve the reference at compile time. It would be nice to have an official word.

Yeah... no. There is no way for such references to be resolved in advance in dynamic languages like Lua or BrightScript, where X.Y is just a shortcut for X["Y"] and not a numeric offset inside a record. You don't know what's in `m` till you get to `m`.

According to my experimentation and the explanation from RokuMarkn here, you are incorrect... viewtopic.php?f=34&t=83110&p=476841#p476844

[NewManLiving]

i could see where you are coming from EnTerr, but an m pointer is specific to an AA and its members which is the reason I speculate. I would think some optimization would occur. Would appreciate something official

[EnTerr]

"TheEndless" wrote:

"EnTerr" wrote:
There is no way for such references to be resolved in advance in dynamic languages like Lua or BrightScript, where X.Y is just a shortcut for X["Y"] and not a numeric offset inside a record. You don't know what's in `m` till you get to `m`.

According to my experimentation and the explanation from RokuMarkn here, you are incorrect... viewtopic.php?f=34&t=83110&p=476841#p476844

Thanks for the reference - seems now X.Y and X["Y"] may differ in B/S. I will back-pedal 1/4 of a revolution (see strike-through above). One can go half-way with dotting by pre-computing hashes, which is neat if you can afford the labor.

Local variable still would be faster. Per quote above, last year my test showed 10x difference.
What do you experiments show now?