Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright

Ruby constants

For general discussion related FlowStone

Re: Ruby constants

Postby digitalwhitebyte » Sat Feb 09, 2013 3:47 am

Regarding the use of self
I do not know, maybe I misunderstood what you wanted to do, but what I mean is displayed in the attached file.
Attachments
test_const.fsm
(381 Bytes) Downloaded 880 times
User avatar
digitalwhitebyte
 
Posts: 106
Joined: Sat Jul 31, 2010 10:20 am

Re: Ruby constants

Postby MyCo » Sat Feb 09, 2013 5:02 am

digitalwhitebyte wrote:I do not know, maybe I misunderstood what you wanted to do, but what I mean is displayed in the attached file.


I don't get it, what do you want to demonstrate with this?

What I wanted was a constant that only exists inside one single RubyEdit... you can do that with a static or an instance method, in this case it doesn't matter. But why use static? it is longer and has no advantage at all
User avatar
MyCo
 
Posts: 718
Joined: Tue Jul 13, 2010 12:33 pm
Location: Germany

Re: Ruby constants

Postby digitalwhitebyte » Sat Feb 09, 2013 5:40 am

HAHA long debate on the "self"
I know that I tell you, you already know,
but have another point of view on this clarifies the ideas too.
however, I understood this from my readings, in ruby, static method are called class methods

def self.method_name
end
defines a class method

def method_name
end
defines an instance method
User avatar
digitalwhitebyte
 
Posts: 106
Joined: Sat Jul 31, 2010 10:20 am

Re: Ruby constants

Postby trogluddite » Sat Feb 09, 2013 1:56 pm

digitalwhitebyte wrote:def self.method_name
end
defines a class method

def method_name
end
defines an instance method

If you are within the namespace of a class, then yes that is correct...
Code: Select all
class myKlass
  # in here, self = myKlass

  def self.method
     # in here, self = myKlass.
  end

  def method
     # in here, self=the object instance
  end

end

But if it is not wrapped in a class definition, then self = the RubyEdit instance, so you are defining a singleton method of the RubyEdit object...
Code: Select all
def self.hello
"hello"
end

def goodbye
"goodbye"
end

hello #=> "hello"
goodbye #=> "goodbye"
singleton_methods #=> ":loadState, :saveState, :hello, :goodbye"

So if you are not within a Class/Module definition context, adding 'self' makes no difference, because the RubyEdit instance is the implicit 'self' anyway.
The class in the RubyEdit instance context is a proxy singleton class for the individual object which inherits from the RubyEdit base class. You can do something similar for any object...
Code: Select all
a = "hello"
b = "goodbye"

a.define_singleton_method(:ouch){"a is #{self}, ouch"}

a.ouch  #=> "a is hello, ouch"
b.ouch #=> <undefined method "ouch" for "goodbye"; String>

So we've added a method that only applies to string 'a' - which will also continue to respond to any other String instance methods, as String is still its superclass. String 'b' remains unaffected because the base class has not changed in any way.
This is effectively what is happening when we create a "classless" definition inside a Ruby primitive - everything is executed in the context of the instance, not the class.

This is actually pretty clever work by the DSPr boys - it's what allows every Ruby editor access to all of the built-in methods, while letting us define our own methods which are only visible to the individual primitive.

The next step will be to similarly isolate plugins/schematics from each other to avoid class/nodule sharing- I've emailed Malc with a couple of ideas for how this might be achieved, and he sounded positive about it, so I'm hopeful that we'll see that improved some time soon.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1730
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Previous

Return to General

Who is online

Users browsing this forum: No registered users and 92 guests

cron