Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
So I have three classes:
MyModule::Base
MyModule::Artist
MyModule::Song
MyModule::Artist inherits from MyModule::Base and therefore has access to all of its instance methods and is declared as such:
module MyModule
class Artist < MyModule::Base
And this all works as expected.
However, when I attempt to add a third class (MyModule::Song) to inherit also from MyModule::Base like so:
module MyModule
class Song < MyModule::Base
I get a NameError. 'Uninitialized constant'. Like MyModule::Base doesn't even exist! Am I missing something fundamental about class inheritance in Ruby or is it something else?
Thanks.
I took a look at your repo and discovered that while you correctly require your Base module via require_relative in Artist, you use a sledge-hammer require to crack nuts in Song.
Since there is kinda system-wide base, it’s being loaded instead of intended local Echonest::Base. Just go with require_relative and enjoy.
Hope that helps.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
What's the benefit of putting all my methods inside a Module?
module Math
def Math.print_message
puts "Testing 123 ..."
end
end
If I just write "print_message" in the file and then require the file from within another file, then I can call "print_message" as well.
What's the advantage of having it within this Module-end construct?
Some Things a Ruby Module Can Do for You
In many ways, modules act a lot like classes, although you can't actually instantiate them. There are quite a number of reasons to put code, classes, and other objects inside modules. These include:
Namespacing, to prevent collisions between same-named constants, classes, methods, and variables.
The ability to compose or extend classes, rather than relying on Ruby's single-inheritance model by "mixing in" modules. That's why modules in Ruby are often called mixins.
The ability define class and module level methods that don't need to be instantiated to be used.
The ability to hook the inclusion of modules to create certain behavior when you mix them into other classes.
Support for autoloading.
The ability to adjust the lookup order of the class hierarchy depending on whether you include or prepend a module.
Support for refinements (see Module#refine and Module#using).
There are likely other things that I haven't thought about in this quick, off-the-cuff answer. However, modules are essential building blocks for gems and larger Ruby applications, and understanding them is worth doing, especially if you're planning to grow beyond basic scripting with Ruby.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
Object-oriented languages can be categorized into two:
Class-based: like C++
Prototype-based: like JavaScript.
Ruby has class, so it is class-based. But its class is also an object. So is Ruby still a class-based language, or is it something in between? Is this a third category?
EDIT:
Ok, what I was wondering is, is other class-based language doing same thing like ruby, like create a class object of class Class?
In an object-oriented language, what else would a class be, than an object? If one of the most important things in an object-oriented language weren't an object, then the language wouldn't be very object-oriented, would it?
Classes are objects in many class-based OO languages. Smalltalk, Python, Ruby, Newspeak, you name it. There are some languages where they aren't, e.g. Java and C#, but even there you can get a reflective proxy object which represents a class.
Class is an instance of Class class. There is nothing in Ruby that goes against it being class based.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Sometimes I see code like
class Thing
def self.add_em(a,b)
a+b
end
end
and sometimes I see
class Thing
def self.add_em(a,b)
#a=a
#b=b
#a+#b
end
end
When/Why should I use the # instance variables instead of just using the parameters as passed?
I believe that one reason is if you want to use those variables in any other method then instance variables will be available and local, parameter based variables will not. However I frequently see # variables being used even though the variables are not being used in any other method.
So I see the pattern of
#a=a
#b=b
at the start of method for all parameters passed in being used a lot but I'm not clear exactly why if they are just used on that method. Is it just a convention in case they are used in other methods?
As you correctly realized, it does not make sense to define instance variables unless they are used in another method. If instance variables are used but are not called in any other method, then that code is probably not written by a good programmer.
But note that sometimes, method definitions are not obvious at first look. For example, if there is
class Thing
attr_reader :a
end
then there actually is a method that uses #a.
I'd say that they did it because they had plans to reference the arguments as instance variables. If not they failed the YAGNI (you aint gonna need it principle). If they changed their minds half way through (which has been known to happen...), they they forgot to tidy up.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
When we try to redefine a constant, Ruby shows only a warning, but not any error. So one can always redefine a constant in Ruby?
Also a private method of a class can be invoked using the send method:
Const = 12
puts Const
#only an warning: already initialized constant Const
Const = 14
puts Const #Displays 14
class MyClass
private
def priv
puts 'In private method'
end
end
obj = MyClass.new
#Error: private method `priv' called for #<MyClass:0x7f2cfda21738> (NoMethodError)
#obj.priv
#but this is fine!
obj.send(:priv)
Are there any rationale behind such designs in Ruby? Do not these violate the basic idea of constants and access specifiers respectively?
Is there any real, practical use of these designs? Some examples would be great if there are!
Note: I do see a lot of questions/discussions here regarding Ruby's constants and private methods, but I did not find anything related to the reason behind these.
As for send, the answer is rather simple: once you use reflection, all bets are off. Note that this is no different than in most other languages as well, you can also circumvent access restrictions in Java using reflection, for example.
And for constants, well, you do get a warning. You do get told that you are doing something you shouldn't. But Ruby is a language which trusts you that you know what you are doing. It won't get in your way. If you want to shoot yourself in the foot, you should be allowed to do that. Or, a more cynical way to look at it: there are so many evil things you can do in Ruby, redefining constants really doesn't matter that much.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
What frameworks exist to add AOP to Ruby?
With Ruby 2.0+, you don't necessarily need a framework:
module BarkLogger
def bark
puts "Logging ##name's bark!"
super
end
end
class Dog
prepend BarkLogger
def initialize(name)
#name = name
end
def bark
puts "##name the dog says bark!"
end
end
Dog.new("Rufus").bark
Output:
Logging Rufus's bark!
Rufus the dog says bark!
You haven't specified any criteria for evaluating different frameworks, so here's one that I found after 3 seconds on Google: Aquarium.
Another one, suggested by #Telemachus: gazer.
Shameless plug: aspector could be what you are looking for. It allows you to define aspect and then apply to one or more targets.
I tried 2 or 3 years ago Aquarium gem at university project. Worked nice, aim of project was comparing with AspectJ, to find out if it is capable of all things as AspectJ. At that time a lot of functionality, which AspectJ was capable of, was missing. But now I see a many things were added, so it's worth a try again.
AspectR (last release looks like in 2002) - originally the canonical AOP library in Ruby.
Facets - has some AOP functionality.