When to use a class vs. module extending self in Crystal? - class

In Crystal, there's two different ways to achieve similar results:
Creating a class...
class Service
def self.get
# ...
end
end
or a module extending self:
module Service
extend self
def get
# ...
end
end
Both can invoke the method get by Service.get.
But when to use a class or a module? What's the difference between Crystal's classes and modules?

There is not much difference between class and module regarding definition of class methods. They are however fundamentally different in the fact that a class defines a type that can be instantiated (Service.new). Modules can have instance methods as well, but they can't be instantiated directly, only included in a class.
If you only need a namespace for class methods, you should use module. class would work fine for this too, but conveys a different meaning.
Btw: While you can't extend or include a class, in a module you can write def self.get instead of extend.

But when to use a class or a module?
Use a module. In this way a module can be used as a namespace.
What's the difference between Crystal's classes and modules?
A module cannot be instantiated, and can be included inside a class
See: Modules documentation

Related

Is there an empty data class in SystemVerilog that is similar to "Object" in Java?

I was wondering if SystemVerilog has a generic class handler similar to how Java has an "Object" class or how C has a void*?
If so, what is it called? What I'm trying to do is have a class that when it is instantiated is passed a defined object, however it could be any object. So, I'm hoping that I can have an empty handler to this unknown data class (or generic) and I'm hoping that I don't have to create an empty data class and use one that is already part of the SystemVerilog library.
I should add that I'm not using UVM or any other methodologies, otherwise I would have just started from a uvm_component or uvm_object.
Java's Object class is the root base class of all classes. There is no such root class in SystemVerilog.
The UVM's uvm_object provides the functionality you are looking for and I suggest using it if for nothing else.

difference between inherit Directive and INHERIT Configuration Directive in bitbake

I am new to bitbake and i am learing it.
Can you please help me understand the difference between inherit Directive and INHERIT Configuration Directive?
My understanding on inherit Directive:
inherit Directive is used to inherit a class from .bbclass file into another .bbclass file or .bb(recipe) file
I am not able to understand what is INHERIT Configuration Directive?i saw the syntax INHERIT += "abc".what is it trying to do?why do we have 2 different inherit directives?
Thanks in advance
The difference between inherit and INHERIT is simple and is well explained in the Yocto documentation here:
... using INHERIT to inherit a class effectively inherits the class
globally
So, there are two differences between them:
Inheritance scope:
inherit only inherits a class for a given recipe
INHERIT inherits the class globally for all recipes, so all recipes have access to the classes functions or tasks, meaning if you have main tasks in that class (do_install, do_compile, ...) it will affect all recipes.
Execution:
inherit will execute any anonymous function in the class during parsing
INHERIT will ignore any anonymous function in the class during parsing (check link)
NOTE
You can develop your own class for example having your utility functions and use it globally by multiple recipes rather than inheriting the class for each class.

What do parentheses do after a class is called?

I have been trying to make a simple player class that contains all of the important player functions in python. I was just getting into the pygame module, when I noticed a class used parentheses. I took the time to learn what a class does in python, but, couldn't find why parentheses are used after for a class. Here is my main code.
class plr(pygame.sprite.Sprite):
def __init__(self):
plr.__init__(self)
self.image = pygame.Surface((20,20))
self.image.fill(black)
Any explanations?
The parentheses at the end of the line in a class statement surround the base classes of the class you're defining. In the common case, there's just one base class (which may be object if no other base class is needed). In Python 3, you can omit the base class and object will be used by default, but you should always explicitly name object (or some subclass) as a base in Python 2, or you'll get an "old-style" class which is something you probably don't want. (Old style classes are quite thoroughly obsolete and not worth learning about if you're new to Python. They don't exist any more in Python 3.)
Specifying a base class lets your new class inherit methods and other behavior from the base class. Inheritance is a key part of Object Oriented Programming, so you'll probably encounter it quite a bit!
In your specific example, the plr class is inheriting from pygame.sprite.Sprite. That means you can call Sprite methods on instances of plr, and they'll usually just work. You can override some of them, if you want to customize your object's behavior.
I do see an error in your code. The __init__ method you've written will recurse infinitely, since it calls plr.__init__, which is itself! You probably wanted it to call pygame.sprite.Sprite.__init__, which is overriding. You can make that call either with the long name I mentioned above, or by using super (which is nicer). Try:
class plr(pygame.sprite.Sprite):
def __init__(self):
super(plr, self).__init__()
...

What is an equivalent of MooseX::NonMoose for Moo?

I would like to use Moo instead of Moose, but I also need to inherit from non-Moose classes. How should I deal with that? Is there a module to work around this? If not, is there a way I can handle it myself?
Moo can handle subclassing non-Moo/Moose classes already. You don't need an extension.
See the documentation for FOREIGNBUILDARGS, which states:
If you are inheriting from a non-Moo class, the arguments passed to the parent class constructor can be manipulated by defining a FOREIGNBUILDARGS method. It will receive the same arguments as BUILDARGS, and should return a list of arguments to pass to the parent class constructor.

Preferred way of grouping utility functions in Scala?

What's the best way of grouping utility functions that don't belong in a class? In Ruby, I would have grouped them in a module. Should I use traits in Scala for the same effect, or objects?
Usually, I put utility functions that are semantically different into different traits and create an object for each trait, e.g.
trait Foo {
def bar = 1
}
object Foo extends Foo
That way I'm most flexible. I can import the utility functions via an import statement or via with in the class declaration. Moreover I can easily group different utility traits together into a new object to simplify the import statements for the most commonly used utility functions, e.g.
object AllMyUtilites extends Foo with Foo2
Package objects or just plain objects.
See, for instance, Scala.Predef and scala.math.
Traits if you want them to be mixed in with the classes that are going to use it. Objects if you want to only have to import them.