sketchucation logo sketchucation
    • Login
    ℹ️ Licensed Extensions | FredoBatch, ElevationProfile, FredoSketch, LayOps, MatSim and Pic2Shape will require license from Sept 1st More Info

    Instance @variable vs class @@variable

    Scheduled Pinned Locked Moved Developers' Forum
    19 Posts 8 Posters 1.8k Views 8 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M Offline
      MartinRinehart
      last edited by

      @unknownuser said:

      Classes are simple and straightforward in Ruby

      That's certainly true, but please explain why:

      
      class MyUniqueName
          # funcs and vars here
      end
      
      

      is better than:

      
      module MyUniqueName
          # funcs and vars here
      end
      
      

      Author, Edges to Rubies - The Complete SketchUp Tutorial at http://www.MartinRinehart.com/models/tutorial.

      1 Reply Last reply Reply Quote 0
      • fredo6F Offline
        fredo6
        last edited by

        Martin,

        A Class allows to create instances, which are designated by variables, so very easy to manipulate.
        It is also a good way to encapsulate an interface (what SU does with the Sketchup::Tool placeholder class)
        Within the class statement, you can declare methods with their name, without any prefixing.

        Personally, I always declare classes within modules. Classes is a way to manipulate objects, whereas module is a way to package the script and provide privacy via a namespace.

        Fredo

        1 Reply Last reply Reply Quote 0
        • J Offline
          Jim
          last edited by

          For a typical plugin that uses a module strictly as a namespace, an instance variable (@anytyhing) can be thought of as "global" within the module.

          
          module MyMod
            @var = 1
            def MyMod.one
              @var # <- this is the same @var
            end
            def self.two
              @var # <-- the same @var
            end
          end
          
          

          Even if the module is split across files.

          
          # File1.rb
          module MyMod
              @var ||= 1
              def MyMod.one
                  @var ||= 2
                  p @var
              end
          end
          
          #File2.rb
          module MyMod
              @var ||= 3
              def MyMod.two
                  @var ||= 4
                  p @var
              end
          end
          
          

          Technically, instance variables are bound to self, so you need to be able to resolve what object is self to know which instance variables are in scope.

          I think a class variable will have the same visibility when used the same way in a module, but for a different reason.

          Hi

          1 Reply Last reply Reply Quote 0
          • M Offline
            MartinRinehart
            last edited by

            @unknownuser said:

            Within the class statement, you can declare methods with their name, without any prefixing.

            I find Ruby's insistence on self.xxx to define module-level functions is quite a nuisance. On the other hand, if you create a singleton instance of your class, then to manipulate anything you have to instance.xxx() whereas in the module you can call your functions without a prefix.

            In practice, both my Rubies have used classes within modules but that's because I converted original module-less code to module-enclosed code, classes and all.

            Author, Edges to Rubies - The Complete SketchUp Tutorial at http://www.MartinRinehart.com/models/tutorial.

            1 Reply Last reply Reply Quote 0
            • M Offline
              MartinRinehart
              last edited by

              @jim said:

              For a typical plugin that uses a module strictly as a namespace, an instance variable (@anytyhing) can be thought of as "global" within the module....

              Even if the module is split across files.

              Didn't know that you could have instance vars in modules, nor that you could split modules across files. Thanks.

              Author, Edges to Rubies - The Complete SketchUp Tutorial at http://www.MartinRinehart.com/models/tutorial.

              1 Reply Last reply Reply Quote 0
              • J Offline
                Jim
                last edited by

                @martinrinehart said:

                Didn't know that you could have instance vars in modules, nor that you could split modules across files. Thanks.

                It's one Ruby's hallmark features (for better or worser) - you can re-open a class at any time and add to it, or redefine what's there.

                Hi

                1 Reply Last reply Reply Quote 0
                • N Offline
                  NewOne
                  last edited by

                  @jim said:

                  For a typical plugin that uses a module strictly as a namespace, an instance variable (@anytyhing) can be thought of as "global" within the module.

                  I think a class variable will have the same visibility when used the same way in a module, but for a different reason.

                  Before starting this post (and that was the reason for the post), I had some problems with instance/class variables. I noticed that instance variables act something like "globals" inside a module, but something strange happened with class variables. I could not acces class variables from outside class. I am not sure yet what was the cause...

                  1 Reply Last reply Reply Quote 0
                  • N Offline
                    NewOne
                    last edited by

                    As I leaned since now, in ruby, variables don't store data, instead they are pointing to value. But I don't know if class variables have pointers or not? Do they are static or dynamic?

                    1 Reply Last reply Reply Quote 0
                    • M Offline
                      MSP_Greg
                      last edited by

                      Boy, a lot of topics in this thread. Here's an old programmer's brief thoughts...

                      Why use Classes - Use classes when 'things' have data/properties. I have code that exports faces from SU to a text file. One format requires all the coordinates be listed together (with an ID) in the text file. My code loops thru the faces and creates an object from each face, with layer, material, etc and coordinate info as instance variables. The loop code creates a few hashes for the coordinates; the face objects can reference that after it's created. If I didn't use classes, I'd be screwing around with crazy arrays and all sorts of stuff. Years ago, that's how one had to code, B4 OOP.

                      Class vs Instance - Using the above example, I use class variables for switches that affect all the objects, like what data to export. Also, the coordinate hashes are class variables.

                      All of my web dialogs are classes, not because I create a lot of them, but because the class holds data. Both data for the dialog, and data that exists after a modal dialog is closed, like the choices a user picked.

                      Keep in mind that classes are very generic and designed so that the user can't get at the internals. That's what setters/getters are for, so the designer, if needed, can validate changes made by an object's user.

                      HTH,

                      Greg

                      1 Reply Last reply Reply Quote 0
                      • D Offline
                        david.
                        last edited by

                        @newone said:

                        @jim said:

                        For a typical plugin that uses a module strictly as a namespace, an instance variable (@anytyhing) can be thought of as "global" within the module.

                        I think a class variable will have the same visibility when used the same way in a module, but for a different reason.

                        Before starting this post (and that was the reason for the post), I had some problems with instance/class variables. I noticed that instance variables act something like "globals" inside a module, but something strange happened with class variables. I could not acces class variables from outside class. I am not sure yet what was the cause...

                        You shouldn't be able to access class variables outside a class (object instance) without using an accessor (a reader and/or writer). Same goes for instances variables. That's part of the reason for using classes. There really are no global variables except true global variables (eg, using '$' as the first character of the name). And, Module vars are not globally scoped, they are Module scope only.

                        Class vars are visible (or shared) to all object instances of a class. Instance vars are visible only to a specific object instance of a class. That is why I gave the simple example using the truck above. Neither is visible outside an object instance without an accessor (using either a class method or attribute accessor).

                        You should check out the freely available online doc... Programming Ruby for more details about classes and variables in Ruby.

                        1 Reply Last reply Reply Quote 0
                        • Dan RathbunD Offline
                          Dan Rathbun
                          last edited by

                          @martinrinehart said:

                          @unknownuser said:

                          Within the class statement, you can declare methods with their name, without any prefixing.

                          I find Ruby's insistence on self.xxx to define module-level functions is quite a nuisance. On the other hand, if you create a singleton instance of your class, then to manipulate anything you have to instance.xxx() whereas in the module you can call your functions without a prefix.

                          You don't need to prefix methodnames in modules. Use a class << self block wrapper around all the methods inside the module.

                          See my post: [info] Using Ruby Modules

                          I'm not here much anymore.

                          1 Reply Last reply Reply Quote 0
                          • 1 / 1
                          • First post
                            Last post
                          Buy SketchPlus
                          Buy SUbD
                          Buy WrapR
                          Buy eBook
                          Buy Modelur
                          Buy Vertex Tools
                          Buy SketchCuisine
                          Buy FormFonts

                          Advertisement