aesthetic question : Compilation module method

[nio kasgami]

Hi guys I was woundering when you do a module.....

exemple you call a configuration like a font comparaison

you will call like this : 

def draw_text_title @text = Sprite.new @text.z = 100 @text.bitmap = Bitmap.new(Graphics.width, Graphics.height) @text.bitmap.font.size = TITLE[:size] @text.bitmap.font.name = TITLE[:font] @text.bitmap.font.italic = TITLE[:italic] @text.bitmap.font.bold = TITLE[:bold] @text.bitmap.font.outline = TITLE[utline] @text.x = TITLE[:x] @text.y = TITLE[:y] rect = Rect.new(0, 0, Graphics.width, Graphics.height / 2) @text.bitmap.draw_text(rect, $data_system.game_title, 1) endthis seem alright ...but if you take the TITLE module calling....if you call to much longer on the same line this will become a little unreadable no? 

like this exemple 

@title.amp = (Exemple[:wave],Exemple[:amplitude],Exemple[:speed])do you think this not a little big? I mean ....this not better to all stuck this kind of module call like this? 

def getting_module_information # System module information @file = SYSTEM[:bgm_name] @volume = SYSTEM[:bgm_volume] @pitch = SYSTEM[:bgm_pitch] # gameover logo module information @font_name = "" @font_size = "" end so in simple all the module information will be store in variable and in the SAME method.

the result in script!

def play_gameover_music # storing module information RPG::BGS.stop case SYSTEM[:me_or_bgm] when "BGM","bgm" return RPG::BGM.new(@file,@volume,@pitch).play when "ME","me" RPG::BGM.stop return $data_system.gameover_me.play end end Why ? simply this remove the fact you have to run all the script for know what configuration run what ! 

but this simply my opinion and please do not critique how I call my stuff (exemple SYSTEM[:ect]) this how luna engine do and I love this way because this clean and work great! 

I just want to know what you think of the module method and how you do your own way !

on this thanks for reading!

 

[Tsukihime]

Would I use a hash constant over storing them in instance variables and then referencing those variables instead of accessing the hash directly?

Maybe.

It provides a layer of abstraction that allows me to hide how I have decided to store my data so that if I decided a hash wasn't a good idea, I don't have to worry about breaking other people's scripts that assumed I used a hash.

module MyData Data = {} Data[:volume] = 120 Data[itch] = 100 def self.volume Data[:volume] end def self.pitch Data[itch] endendHere, I would recommend other scripters use the interface I have provided, rather than accessing the Data hash directly.They could of course say

MyData:ata[:volume]If they wanted to because nothing's stopping them, but if I decided to change :volume to :volume2 or something, they would need to update their own scripts.By providing an interface, it would increase compatibility in case of future changes.

 

[Galenmereth]

In this example I'd do this instead:

def settings SYSTEMenddef filename settings[:bgm_name]enddef volume settings[:bgm_volume]enddef pitch settings[:bgm_pitch]endSo that you can do this:

RPG::BGM.new(filename,volume,pitch).playThe benefit of the settings method is that if you change the settings class/module from SYSTEM to something else, you only need to change it once. It's not a necessary thing, but I like it tidy. The benefit of the remaining methods is overall readability, and I prefer to only use instance variables for things that will change; since things like settings in modules usually remaining constant, I believe it's better to not make them into variables because it can confuse the reader of the script on what is going on.

 

[nio kasgami]

I am not sure what you are asking.

Would I use a hash constant over storing them in instance variables and then referencing those variables instead of accessing the hash directly?

Maybe.

It provides a layer of abstraction that allows me to hide how I have decided to store my data so that if I decided a hash wasn't a good idea, I don't have to worry about breaking other people's scripts that assumed I used a hash.

module MyData Data = {} Data[:volume] = 120 Data[itch] = 100 def self.volume Data[:volume] end def self.pitch Data[itch] endendHere, I would recommend other scripters use the interface I have provided, rather than accessing the Data hash directly.They could of course say

MyData:ata[:volume]If they wanted to because nothing's stopping them, but if I decided to change :volume to :volume2 or something, they would need to update their own scripts.

this seem a really good idea I am tempted to follow this method but in same way galentmereth method seem also really interesting both have their own advantage in readability and their both problem like galent pointed 

In this example I'd do this instead:

def settings SYSTEMenddef filename settings[:bgm_name]enddef volume settings[:bgm_volume]enddef pitch settings[:bgm_pitch]endSo that you can do this:

RPG::BGM.new(filename,volume,pitch).playThe benefit of the settings method is that if you change the settings class/module from SYSTEM to something else, you only need to change it once. It's not a necessary thing, but I like it tidy. The benefit of the remaining methods is overall readability, and I prefer to only use instance variables for things that will change; since things like settings in modules usually remaining constant, I believe it's better to not make them into variables because it can confuse the reader of the script on what is going on.

you mark a point here! this seem even better for help and it's even more readable 

thanks for both answer this seem really logic the way you explain that and really easy!