Improving $imported (7/23 Update: Start suggesting keys/values!)

[PK8]

The $imported variable. I wasn't always a huge fan of it... until I made a topic questioning why scripters use it. Once I read the responses to it, I understood its purpose. Since then, I grew to love it for the usefulness it provides. It makes for a great way to check if certain scripts were imported and provide some workarounds or expanded options based around that. Until I started thinking about the things it lacked, such as version checking.

When you think about it, doesn't this seem a little redundant?

$imported[:hello_world] = true

if $imported[:hello_world]

Especially when you could check if the key exists by using this?

$imported.has_key?(:hello_world)

Why don't we start doing more with it?  Let's expand the number of ways a scripter can check for another user's imported scripts. Let's add some data to our keys. Let's start doing things like this:

$imported[:hello_world] = {  :key1 => value1,  :key2 => value2,  :key3 => value3}

If anyone (scripters especially) is for this idea, we could get started on putting together suggestions on making $imported better. Let's come up with some implementations we can all agree upon and use for our scripts.Edit: If anyone would like to lead the discussion, that would be nice.

Edit 2: I never explained why using a hash instead of a boolean value for our $imported keys would be beneficial to us.
For one, we can store information about our scripts into our hashes. If this were to be widely adopted by the community, the implementations of certain name/value pairs we can think of and mostly agree on would provide scripters an array of new options they can use to check for compatibility with their own scripts along with other submitted scripts. You do not have to use these new options for compatibility checks if you don't want to. You would still be able to determine if a script is imported by checking if $imported has a particular key you're looking for stored in its hash.

Two, scripters may be able to use all of this new information to their advantage by creating scripts and snippets centered around the $imported variable. For example, a script logger.

Three, if we were to use hashes for our keys instead of boolean values, the door would always be open for discussions and share new ideas on what we can do to further expand and improve $imported.

 

[PK8]

[Reserving post]

Reason: To keep track of any suggestions that may have been posted in this thread.

 

[nio kasgami]

I love the idea I never really understand the use of $imported in the past so I never use them

 

[TheoAllen]

$imported is a compatibility flag. There're many compatibility flag you could use. Most of scripters might have define their own module, like

module Theo  module ScriptName  endendThen, for compatibility check, you could use this built-in function

if define?(Theo::ScriptName)Version checking is great. I remember one of my friend ever use $imported as this one

$imported[:his_script] = 0.6However, I don't really understand why do you suggest a multiple values inside the $imported and why do you consider it better.

 

[Mithran]

I see no problem with the way $imported is used normally. It is a fast, simple way to see if a specific script has been installed and therefore needs to be accounted for specifically. A scripter may have to examine both scripts to see exactly which provisions need to be made to make scripts work together, but it beats having to jump through hoops and use defined? and other methods to even check if a script is in effect. The biggest problem with everyone using the same variable is name collision, which usually isn't an issue as most who use the hash use semi-unique identifiers (for example, yanfly uses the prefix for YEA- for Yanfly Engine Ace).


If you were to store any data in the keys, a version number of the script would be obvious choice as it would still be implicitly evaluated as true and still fit with the normal community use, but you could personally use it for quick version control.

 

[PK8]

2014-7-22 edit: The spoilers below contains some code I originally wrote that's actually unnecessary to do. Disregard those and view the corrections below the spoilers.

However, I don't really understand why do you suggest a multiple values inside the $imported and why do you consider it better.

If more scripts were to use it, checking for versions and determining whether the script is enabled would be consistent.We could start doing things like this:

Spoiler

if $imported['<user>_<script>'][:ver].to_f >= 1.2 # Do something for version 1.2 or later of a script.elsif $imported['<user>_<script>'][:ver].to_f < 1.2 # Do something for scripts with a lower versionend

if $imported['<user>_<script>'][:ver].to_f >= '1.2'  # Do something for version 1.2 or later of a script.elsif $imported['<user>_<script>'][:ver].to_f < '1.2'  # Do something for scripts with a lower versionend

Or create cases with the string containing the script's version.We could also check whether or not an imported script is enabled and do something with it.

Spoiler

if $imported.has_key?('<user>_<script>') # Imported if $imported['<user>_<script>'][:enabled] # Imported and enabled else # Imported and disabled endelse # Not importedend

if $imported['<user>_<script>']  # Imported  if $imported['<user>_<script>'][:enabled]    # Imported and enabled  else    # Imported and disabled  endelse  # Not importedend

It also opens up the possibility for someone to write a Script Logging system that logs the names, last revision dates, authors, versions (and other useful data) of each script that utilizes $imported, which could in turn potentially make this a pretty advanced compatibility checking system.Edit: For a simpler import check, we could still use

Spoiler

if $imported.has_key?('<user>_<script>')  # Importedend

Or...

key = '<user>_<script>'if $imported.has_key?(key) and $imported[key][:enabled]  # Imported and enabledend

if $imported['<user>_<script>']  # Importedend

Or...

key = '<user>_<script>'if $imported[key] and $imported[key][:enabled]  # Imported and enabledend

 

[Shaz]

You are suggesting that in order for someone to write a script, they need to check what other scripts a developer might be using alongside it, and keep a list, not only of the script, but of every version that they might be running, and make their script compatible with all of those versions? AND keep track of when someone else updates their script so you can change your script accordingly?


WAY too much work. If I want to write a script and release it, I don't want the burden of having to check everyone else's scripts constantly and updating mine every time someone else updates theirs.


But then I don't use $imported. If someone wants to use my scripts with others, it's up to them to worry about compatibility.

 

[PK8]

You are suggesting that in order for someone to write a script, they need to check what other scripts a developer might be using alongside it, and keep a list, not only of the script, but of every version that they might be running, and make their script compatible with all of those versions? AND keep track of when someone else updates their script so you can change your script accordingly?

No. What I'm saying is, if this way of using $imported were to be widely agreed upon, we could establish a revised standard that allows us to add more data to provide other scripters more tools and more options (which they wouldn't be required or need to use unless they find it necessary) to check for compatibility with another script.
If you already do import/compatibility checks in your scripts, then you have nothing to worry about as those can still be done in its most basic manner by checking if the key is included in the $imported hash $imported[key] as usual, which then determines if the script is imported. Again, doing something like checking which version an imported script is on is not necessary unless you absolutely need to do it.


7/22 edit: Correcting myself. One could just check for $imported[key] as they always did.

 

[TheoAllen]

Oh, I see. I'm doing the same in my basic modules. In order to raise compatibility, I make the $imported as a setting, not just only compatibility flag.

For example :

$imported = {} if $imported.nil?$imported[:Theo_Module1] = true$imported[:Theo_Module2] = true$imported[:Theo_Module3] = false$imported[:Theo_Module4] = trueIn fact that not every functions in basic modules are used, right?

Every script I wrote which requires my basic modules, I told the user which modules I use. So, you could disable the rest of unused modules

 

[estriole]

the good example on using imported is victor....

in victor scripts basic module... he use:

$imported[:ve_basic_module] = 1.17module Victor_Engine  def self.required_script(name, req, version, type = 0)    if type != :bellow && (!$imported[req] || $imported[req] < version)      msg = "The script '%s' requires the script\n"      case type      when :above        msg += "'%s' v%s or higher above it to work properly\n"      else        msg += "'%s' v%s or higher to work properly\n"      end      msg += "Go to http://victorscripts.wordpress.com/ to download this script."      self.exit_message(msg, name, req, version)    elsif type == :bellow && $imported[req]      msg =  "The script '%s' requires the script\n"      msg += "'%s' to be put bellow it\n"      msg += "move the scripts to the proper position"      self.exit_message(msg, name, req, version)    end  endendbasically it's version storage... and method to check the order of the scripts.

and in his other scripts...

module Victor_Engine  def self.required(name, req, version, type = nil)    if !$imported[:ve_basic_module]      msg = "The script '%s' requires the script\n"      msg += "'VE - Basic Module' v%s or higher above it to work properly\n"      msg += "Go to http://victorscripts.wordpress.com/ to download this script."      msgbox(sprintf(msg, self.script_name(name), version))      exit    else      self.required_script(name, req, version, type)    end  end  #--------------------------------------------------------------------------  # * script_name  #   Get the script name base on the imported value, don't edit this  #--------------------------------------------------------------------------  def self.script_name(name, ext = "VE")    name = name.to_s.gsub("_", " ").upcase.split    name.collect! {|char| char == ext ? "#{char} -" : char.capitalize }    name.join(" ")  endend$imported ||= {}$imported[:ve_animated_battle] = 1.01Victor_Engine.requiredve_animated_battle, :ve_basic_module, 1.13, :above)Victor_Engine.requiredve_animated_battle, :ve_actor_battlers, 1.00, :bellow)Victor_Engine.requiredve_animated_battle, :ve_animations_settings, 1.00, :bellow)above mean:

the scripts is :ve_animated_battle

the scripts version is 1.01

that scripts NEED :ve_basic_module version 1.13 or above placed ABOVE that scripts

IF you use :ve_actor_battlers version 1.00 or above place it BELOW that scripts if any

IF you use :ve_animations_settings version 1.00 or above place it BELOW that scripts

basically it's a method to tell user if they have outdated basic module 'for' that scripts...

also if they placed it in wrong order... above mean should be placed above that scripts. :below = below... .).

that's clever... BUT if you only use it for your own scripts.

i personally don't really want to check compatibility for every version of other people scripts... just the latest one already drain us to check the code... and add the code to make it compatible.... and most people use the latest version anyway...

in victor scripts above... other people can still use $imported[:ve_basic_module] to check ONLY if the basic module exist.

so... basically it's the best implementation so far...

 

[Tsukihime]

Having a standard way to determine version number of a script, for the purposes of checking whether a newer version exists and to prompt the user to update to the newest script, would be useful.

Every script I wrote which requires my basic modules, I told the user which modules I use. So, you could disable the rest of unused modules

So what happens when the first script uses module3, but the second script doesn't, and then the third script performs a check to see whether a certain module exists?

 

[TheoAllen]

So what happens when the first script uses module3, but the second script doesn't, and then the third script performs a check to see whether a certain module exists?

- The first script will throw an error if you disable the module 3, assumed it only use the module 3

- The second script is independent.

- It depends how do you perform the check. Will it throw an error notice? or use alternative way instead? You could make "This feature is avalaible if you installed this basic modules"

 

[cremnophobia]

Why do people use Floats as version number? That's stupid. Just use a string like RUBY_VERSION or RGSS_VERSION. You can use relational operators with them!

 

[Tsukihime]

Less keystrokes required. What's wrong with using a float?

 

[PK8]

Why do people use Floats as version number? That's stupid. Just use a string like RUBY_VERSION or RGSS_VERSION. You can use relational operators with them!

If you read my reply (Reply #6), it's pretty much implied that I have the version number set up as a string due to my use of #to_f to get the conditionals I need.

Plus, my proposal for the spec would be to have people use strings when specifying version numbers so as to maintain consistency with the aforementioned RUBY_VERSION constant.

Less keystrokes required. What's wrong with using a float?

You wouldn't be able to add a revision number to your script version like you could with a string. And you would also be able to use an alphanumeric character in your string to indicate your script's release type. There are better reasons for it, but those are the only two I can think of right now.
Edit: Another argument against using floats to store your script's version number is that a number like 1.10 would be considered the same as 1.1 (In fact, they are the same). Of course, to most people, this would probably be considered a no-brainer as well as something that's unnecessary to point out, but it's worth a reminder.

 

[Tsukihime]

Oh...yes you're right that would be problematic.


Evidently I've never revised any of my scripts beyond 9 revisions to have to think about what happens if I hit 1.10.

 

[cremnophobia]

I hope we all know that telephone numbers or zipcodes are neither integers nor floats. That the same applies to version numbers might not be as obvious, but here's a simple question: do you want to do maths with version numbers? No, you don't want the sum of four version numbers or just multiply on with another one.

Key strokes aren't a good argument, because scripters don't (seem to) care. You can see that in this thread: Hash#has_key? vs. Hash#key?. We're programming in Ruby and not in C.

If you read my reply (Reply #6), it's pretty much implied that I have the version number set up as a string due to my use of #to_f to get the conditionals I need.

Plus, my proposal for the spec would be to have people use strings when specifying version numbers so as to maintain consistency with the aforementioned RUBY_VERSION constant.

To me that isn't implied. It could be any kind of object which responds to #to_f (even Float). I think we could agree on that being only a good guess. And it still raises the question why floats are involved. RUBY_VERSION-like strings can be compared:
if $imported['<user>_<script>'][:ver] >= '1.2.0' # Do something for version 1.2 or later of a script.elsif $imported['<user>_<script>'][:ver] < '1.2.0' # Do something for scripts with a lower versionendThat isn't optimal though. But it is used in Ruby code and it works. The optimal solution would be having a class like Gem::Version, but I guess nobody wants to write or propose a script package management — RGSSGems!Your proposal sounds great, but you haven't mentioned it before. I like it!

 

[PK8]

Hash#key?

I should've known about Hash#key?! That saves keystrokes and maybe four characters worth of space in a line of code. Yes, little things like that do kind of matter to me. (I'm pretty sure this places me in a fairly extreme minority)

And it still raises the question why floats are involved. RUBY_VERSION-like strings can be compared:

if $imported['<user>_<script>'][:ver] >= '1.2.0' # Do something for version 1.2 or later of a script.elsif $imported['<user>_<script>'][:ver] < '1.2.0' # Do something for scripts with a lower versionend

I just tried it out for the first time and got blown away. Yeah, this pretty much beats using floats now! I just learned something new thanks to you.

The optimal solution would be having a class like Gem::Version, but I guess nobody wants to write or propose a script package management — RGSSGems!

You know, I still have yet to check that out. I might just do that right after I finish posting this reply.Anyway, I'm personally a bit hesitant on the idea as I wouldn't consider it to be part of the goal at this moment. My goal for this thread is to propose an expansion to the already widely supported $imported, garner support and encourage its adoption, and for us to come up with new key/value pairs along with implementations of those pairs we could begin to use for our scripts.

Edit:

Oh...yes you're right that would be problematic.

Evidently I've never revised any of my scripts beyond 9 revisions to have to think about what happens if I hit 1.10.

A possible workaround one could do if they still want to work with floats is to start numbering their minor versions like this:

1.0, 1.01, 1.02, .. 1.09, 1.1, 1.11, 1.12, .. 1.19, 1.2

And so on and so forth. Though that might be a little confusing.

 

[FenixFyreX]

You could just store the version in a string, like

$imported["<name>_<script>"][:ver] = "1.1.0"Open an instance of irb or a game's script tab, and execute this:

puts RUBY_VERSION >= "1.9.0"

It will return true or false depending on the numbers. I think this behavior was written in exactly for this purpose.
I've never personally used $imported, past my second script I've ever wrote. It never caught on for me; I always used "defined?(something)", or wrote compatibility scriptlets after the fact.


I've been thinking about a Gem system for rpg maker, especially since the ability to write extensions isn't far way from RGSS3.

 

[estriole]

A possible workaround one could do if they still want to work with floats is to start numbering their minor versions like this:

1.0, 1.01, 1.02, .. 1.09, 1.1, 1.11, 1.12, .. 1.19, 1.2And so on and so forth. Though that might be a little confusing.

i think you should use 1.00 instead of 1.0 (to prevent confusion like you said)... prepare your version number carefully...

OR just skip to 2.0

ex:

1.0, 1.1, 1.2, 1.3, ... 1.9, 2.0

who care if the version increase because minor / major changes...

and who also care if the version number later become v110.3.

(when i type this... i remember steins gate LOL... time machine name : FG204 2nd edition Ver.2.31 LOL)

personally... if there's super major changes to my scripts (possibly rewrites. i change the integer number instead of float number)

1.5 -> 2.0 like that...

(and i also thought that 10 minor changes is almost the same as 1 major changes to the script.

so it's okay for 1.9 -> 2.0 with only minor change... but that's my opinion)

user won't complaint as long as the script works . (scripter also shouldn't complaint because it still can be compared. just increasing the integer). there's no problem even if coder want to use this as version:

1, 2, 3, 4, 5, 6... 200

but that's my personal opinion .