Proper way for global variables?

[Napoleon]

Spoiler

module DataManager class << self alias_method :nap_make_save_contents_date_data, :make_save_contents alias_method :nap_extract_save_contents_date_data, :extract_save_contents def make_save_contents contents = nap_make_save_contents_date_data contents[:nap] = { :data => Nap.data } return contents end def extract_save_contents(contents) nap_extract_save_contents_date_data(contents) Nap.data = contents[:nap][:data] end endendmodule Nap @@data = ["initial value", "lorem ipsum"] def self.data; @@data; end def self.data=(value); @@data=value; endendp Nap.data

• Instead of $data you must now type Nap.data. I'm not sure if that is better but it has more chances for being unique and $nap_data is not that great imo.
• I also used an alias on the DataManager module for obvious reasons.
• Large projects would use Nap.data.x or Nap.data.y instead of just one data variable using a struct (where possible).

Is this how you would handle this?

 

[Shaz]

What is the purpose of doing it that way?


I wouldn't do it like that - mainly because I can't see what you're trying to achieve.

 

[Ossra]

'$napoleon_data' or something therein would be a more RGSS standardized way to do what you are going for.

 

[Tsukihime]

What is the purpose of doing it that way?


I wouldn't do it like that - mainly because I can't see what you're trying to achieve.

Abstraction would be one reason.


Nap.data is a method call, whereas accessing $nap_data directly accesses the object stored in that variable.


He could change the implementation all he wanted to (eg: change it from an array of arrays to some complex object) and still return the same data so that any existing scripts using it won't break cause they expected it to be an array of arrays.


Whether the abstraction is beneficial, though, is another issue.

 

[Shaz]

If you were going to do that, wouldn't you have to go through ALL the scripts and change any existing reference to $data_* to suit the new method of access? I'm assuming the intention is to package all the existing database into a single entity?

 

[Tsukihime]

I think it would be with custom data going forward.


I wouldn't really change the existing database arrays, and don't see much need to.

 

[Engr. Adiktuzmiko]

if you would do something like Nap.data.x, you would need to make data into another type that has its own methods/data right?

anyway, I prefer the $ way simply because that's the ruby way of doing it...

 

[Napoleon]

I'm sorry for the confusion. $data (not $data_actors or something) does not exist yet and is not related to any existing data. It will contain my custom 'field-data' like the state of certain maps, global dialogues (4 self switches are not enough sometimes) and other things. I should have used another sample name for it I'm sorry...

It will contain basic classes and variables that eventually will be nested a few levels deep. Like

Nap.data.Elisabeth[:trainstation][:hallway_x][:color] = 16 # << probably this one

or

Nap.data.Elisabeth.trainstation.hallway_x.color = 16 # << like adiktuzmiko mentioned, probably too much trouble to make this and there is no code completion in the RGSS editor anyway to make good use of this.

I don't like using the build in $game_variable.

I don't really like the $ in front of it all the time for some reason and I will be typing that variable quiet a lot. Perhaps I will shorten it to $nfd (napoleon field data) instead. It's just personal preference.

Yes the abstraction is another future that the module approach brings. Especially for debugging purpose (now I can see exactly where and who is retrieving/setting the variable) and the extra function call is neglectable in terms of resource usage.

But it seems that either solution is 'proper' and that it is all a matter of personal preference.

 

[Reedo]

Spoiler

module DataManager class << self alias_method :nap_make_save_contents_date_data, :make_save_contents alias_method :nap_extract_save_contents_date_data, :extract_save_contents def make_save_contents contents = nap_make_save_contents_date_data contents[:nap] = { :data => Nap.data } return contents end def extract_save_contents(contents) nap_extract_save_contents_date_data(contents) Nap.data = contents[:nap][:data] end endendmodule Nap @@data = ["initial value", "lorem ipsum"] def self.data; @@data; end def self.data=(value); @@data=value; endendp Nap.data

Spoiler

• Instead of $data you must now type Nap.data. I'm not sure if that is better but it has more chances for being unique and $nap_data is not that great imo.
• I also used an alias on the DataManager module for obvious reasons.
• Large projects would use Nap.data.x or Nap.data.y instead of just one data variable using a struct (where possible).

Is this how you would handle this?

In general I would say yes; it is better to encapsulate your custom data in your own custom object than it is to simply throw new data into the mix using a global variable.  At a minimum this prevents you from creating a pile of new globals for everything you might want to keep track of.

Abstraction and encapsulation are always important to some degree.  I would argue that they remain critical in all circumstances in RGSS3 due to the loose typing of Ruby and unknown number of custom scripts that your script might be expected to play nicely with.