Author Topic: Updated EAConstants-JScript file  (Read 4804 times)

Mhatch

  • EA User
  • **
  • Posts: 27
  • Karma: +0/-0
    • View Profile
Updated EAConstants-JScript file
« on: May 02, 2014, 10:35:51 am »
The default EAConstants-JScript file - included in every new JScript and JavaScript as
Code: [Select]
!INC Local Scripts.EAConstants-JScriptpollutes the global namespace by leaving all the variables global.

I've updated the script to wrap the constants in an object literal, which cleans up the namespace, and unifies the constants with the other EA automation objects by making them accessible through the 'EA.' namespace:
Code: [Select]
Session.Prompt( "Prompt text", [highlight]EA.promptOK[/highlight]);
I'd suggest updating the script and documentation.  If you'd like to update your scripts,  simply copy/paste the script below into a new Normal Script group ('Utilities' in the example below, script name is still 'EAConstants-JScript') and change your includes as follows:

Code: [Select]
!INC Utilities.EAConstants-Jscript
//!INC Local Scripts.EAConstants-JScript

https://github.com/mikehatch/SparxScripts/blob/master/EAConstants.js

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8061
  • Karma: +118/-20
    • View Profile
Re: Updated EAConstants-JScript file
« Reply #1 on: May 02, 2014, 01:07:50 pm »
Nice idea.

Our copy couldn't be changed without breaking existing scripts, so that's very unlikely to happen.

Mhatch

  • EA User
  • **
  • Posts: 27
  • Karma: +0/-0
    • View Profile
Re: Updated EAConstants-JScript file
« Reply #2 on: May 02, 2014, 03:16:52 pm »
Yes certainly wouldn't want to break established customers scripts.  This could be added as a new script, though, and any new scripts created could use the new include as the default.
[edit]I realized another approach would be to simply add the object from my script into the existing script, making the constants available both ways.  Since I've encapsulated all the constants into an 'EA' object, they would not conflict with the existing ones.  A little wasteful because they would all be defined twice, but would allow people to migrate gracefully.[/edit]

Just a thought.  Anyone really anxious enough about this could do it manually as I have done.  (I've been reading a number of javascript patterns & performance books, which highlighted the risks of the javascript global namespaces, which is one of it's weaknesses).

« Last Edit: May 03, 2014, 01:41:35 am by mike.hatch »