[RGSS]A Question on the attr_writer/reader/accessor[Answered]

Started by Shadow Eye31, November 08, 2012, 05:07:49 am

Previous topic - Next topic

Shadow Eye31

November 08, 2012, 05:07:49 am Last Edit: November 08, 2012, 07:06:19 am by Shadow Eye31
Hello there.

I recently had an issue in creating a script due to my lack of general knowledge on RGSS. I have read several articles, tutorials, guides, and topics for learning RGSS, however, I find I learn much faster if I learn in an engaged way. Merely reading an article on a function or topic does not leave the same impression a lesson or conversation would, for example. To this end, I'd like to request some help with understanding attr_writer/reader/accessor.

I recently created a script for creating custom stats which I required help with. KK20 jumped in and provided the solution:

Quote: ShowHide
Quote from: KK20
It's exactly what the message window says: You don't have a 'set' method for your variables. Easy way to do that would be to make your new stats be attr_writer
attr_writer :vit


I noticed you defined your 'get' methods, so I that's why I didn't suggest attr_accessor.


Once I set the attr_writer for all of the new variables I was using, everything worked. If I held a better understanding of these functions, I feel I wouldn't have had this issue. So here I am.

I believe attr_writer/reader provide the writing/reading function to a value, respectively. However, I have little to no understanding of attr_accessor, except that perhaps it provides both of these functions. Beyond those basic statements, I haven't the foggiest impression of their function and how to effectively utilize them.

Bottom Line-
For attr_reader/writer/accessor, would someone mind going in-depth in explaining these for me?
For attr_accessor, how would this differ from using attr_reader/writer and definitions? Is it more effective?

Thank you in advance if you decide to indulge my curiosity.

Blizzard

November 08, 2012, 05:24:18 am #1 Last Edit: November 08, 2012, 05:31:47 am by Blizzard
Here are the equivalents for these declarations.

class A
 
 attr_writer :vit
 
 # does the same thing as attr_writer
 def vit=(value)
   @vit = value
 end
 
end


class A
 
 attr_reader :vit
 
 # does the same thing as attr_reader
 def vit
   return @vit
 end
 
end


class A
 
 attr_accessor :vit
 
 # does the same thing as attr_accessor
 def vit
   return @vit
 end
 
 def vit=(value)
   @vit = value
 end

end
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Shadow Eye31

Thanks for helping me out a bit on this. It's good to see the comparison.

Is there a definite advantage to using one over the other? Obviously, there's less code in using a declaration, so I mean aside from that.

Thanks in advance.

Blizzard

Basically it's simply shorter to use attr_accessor instead of attr_writer and attr_reader separately (and your code looks cleaner).
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Shadow Eye31

Simple enough.

So, to ensure I am understanding everything, let's say I have this code:

class Game_Actor < Game_Battler

  attr_accessor   :vit

  alias alias_setup setup
  def setup(actor_id)
    alias_setup(actor_id)
    @vit = 0
  end

end


I would be able to call, use, and rewrite vit at will in other classes? Such as below:

class Scene_Awesome

  def awesomer
     if @actor.vit <= 9000
        @actor.vit += 1
     end
  end

end


Or would I still have to make a def vit somewhere to utilize it?

I apologize for pestering you with this, and thank you for helping me thus far.

Blizzard

Yes, that's all you need. There is no need for any additional method definitions.

Don't worry, we're all here to help.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Shadow Eye31

Got it. Thank you for all your help. Its been very, well, helpful!

Heretic86

I'll also point out that one of the differences is for Security Purposes.  Although security isnt an issue in RMXP, if you used Ruby for a Website, you may have more need of it.

For example, SQL Injection Attacks can occur because external input isnt checked for security. 


def value=(value)
  return unless is_secure?(value)
  @value = value
end


So if you tried something like foo.value = "Erase the Database", you can check the values passed before assigning the values. 

You might also want to use some Type Checking as well.  Say you write somethign that expects a Number, and someone passes an Object to it, that can cause you trouble in the stability of your program.  You can use Get Methods to maintain your programs stability as well.
Current Scripts:
Heretic's Moving Platforms

Current Demos:
Collection of Art and 100% Compatible Scripts

(Script Demos are all still available in the Collection link above.  I lost some individual demos due to a server crash.)

Blizzard

If you actually allow commands like "DROP DATABASE 'name'", then your security problem lies elsewhere. It really depends on what the purpose is of your code. If you are distributing code for systems that need to be secure or specifically designed systems and a clearly defined interface, then you need these types of checks (and you may actually be using the completely wrong language in this case as this is not what Ruby was intended for). But if you are distributing scripts that people can edit, then this stuff isn't really needed since people should be able to add their own hacks as they please.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.