I would like to override the values of another class in another Puppet Modules. Please help me by suggesting ways.
Existing Class : ( Module Name : MySQL )
class mysql::server (
$config_file = $mysql::params::config_file,
$includedir = $mysql::params::includedir)
{
My Code Logics
}
My Current Class : ( Module Name : Profiles )
Class profiles::mysql () {
class { '::mysql::server':
config_file => '/opt/arunraj',
includedir => true
}
}
When i am doing like above, I am getting duplicate class declaration error. Which is a best way to override a values between two classes
In the first place, your example code is incomplete. You present the definitions of classes mysql::server and profiles::mysql, and the latter contains a resource-style declaration of class mysql::server, but you say nothing about the one or more other declarations of class mysql::server that the given one collides with. What you actually presented is not enough to produce the error you describe.
Note also that using resource-style class declarations is usually poor form, especially for declaring public classes of any module, and most especially for declaring classes belonging to a different module than the one in which the declaration appears. The reasons are a bit technical, but to a large extent they boil down to the risk of eliciting exactly the kind of error you encountered. That happens whenever Puppet evaluates a resource-style declaration of a class for which a declaration (in any style) has already been evaluated, because class parameter values are bound as part of evaluating the first-encountered declaration.
The best way to customize class parameter values is to rely on automatic data binding (Hiera) to bind values to those parameters in the first place. If you have an oddball machine that needs different parameter values then you set them at a higher-priority level of your data hierarchy than the one from which the ordinary values come, and which is scoped narrowly enough to avoid affecting machines that should have the ordinary parameters.
Moreover, to avoid the kind of error you describe, you should also be certain everywhere to use only include-like declarations for any class that might be declared more than once (i.e. any public one, and some private ones). That goes hand in hand with automatic binding because if you don't use resource-like declarations then automatic data binding is your best available means for customizing class parameter values. The classical include-style declaration is via the include function itself, but the require, contain, and hiera_include functions also provide include-style declarations (with various differences in semantics). If you're using an ENC to declare classes then it might produce either style.
Related
I'm new at Kotlin, migrating from Java. One thing I think is a little bit confusing is the fact we may declare a function using different ways. Bellow are at least 3 ways to accomplish that:
package me.bruno.santana
class MyClass {
fun square(number: Int) = number * number
fun square2(number: Int): Int{
return number * number
}
}
fun MyClass.square3(number: Int) = number * number
fun main(){
val obj = MyClass()
println(obj.square(3))
println(obj.square2(3))
println(obj.square3(3))
}
What is the difference between this 3 ways in practical terms? I know the last one is related to extension funcion concept, but I don't know what it differs from the conventional way in practical terms.
Another thing is weird for me is the assignment in the function definition(using equals sign to associate the function's body to the function's signature). Is it in any way different from the convetional way using curly braces as in Java?
Thank you.
1. This is single expression function:
When a function returns a single expression, the curly braces can be omitted and the body is specified after a = symbol
Explicitly declaring the return type is optional when this can be inferred by the compiler:
fun square(number: Int) = number * number
2. This is normal function
That can have single-line or multi-lines and required return type (but Unit is optional):
fun square2(number: Int): Int {
return number * number
}
3. This is Extension functions:
Kotlin provides the ability to extend a class with new functionality without having to inherit from the class or use design patterns such as Decorator.
Extensions are resolved statically: Extensions do not actually modify classes they extend. By defining an extension, you do not insert new members into a class, but merely make new functions callable with the dot-notation on variables of this type
Often used to write utility functions and enhance readability via dot-notation.
If an extension is declared outside its receiver type, such an extension cannot access the receiver's private members.
fun MyClass.square3(number: Int) = number * number
To add something about extension functions: there are four common reasons to use them that I can think of.
You don't control the source code of the class you're adding the function to.
You want to add functions only to specifically typed instances of a class. For example, you could write a function for your Foo<T: Animal> class that is only available on instances that are a Foo<Pet>.
You want to add something like a final function to an interface. This is used frequently in the standard library. If you define a function inside an interface, its behavior is unpredictable because interface functions cannot be final. By declaring it outside the interface as an extension, it can be hidden (by writing a different extension function with the same signature), but it cannot be overridden. Hiding it still requires the user to import the other version of the function, so it must be done explicitly.
You want to confine the scope of the added function. Maybe the function only really makes sense in a certain context, so you don't want it to clutter the IDE auto-complete everywhere. Or maybe it uses a property of a certain class, so it must be defined within that class.
When you're just composing one of your own typical classes, you won't frequently need to use an extension function.
Ok, so this might be me being pendantic but I need to know the best way to do something:
(This is psudocode, not actual code. Actual code is huge)
I basically have in my package a class that goes like this:
internal class charsys extends DisplayObject {
Bunch of Variables
a few functions
}
I another class which I intend to add to the timeline I want to create a function like this:
public class charlist {
var list:Array = new Array();
var clock:Timer = new Timer(6000);
var temp:charsys;
function addObj(MC:DisplayObject, otherprops:int) {
temp=MC;
temp.props = otherprops;
list.push(temp)
}
function moveabout(e: event) {
stuff to move the items in list
}
function charlist() {
stuff to initialize the timers and handle them.
}
}
So the question is, is my method of populating this array a valid method of doing it, is there an easier way, can they inherit like this and do I even need to pass the objects like I am?
(Still writing the package, don't know if it works at all)
Yes, you can pass an object into a function, but you should be careful of what you are planning to do with that object inside that function. Say, if you are planning to pass only charsys objects, you write the function header as such:
function addObj(MC:charsys, otherprops:int) {
Note, the type is directly put into the function header. This way Flash compiler will be able to do many things.
First, it will query the function body for whether it refers to valid properties of a passed instance. Say, your charsys object does not have a props property, but has a prop property, this typing error will be immediately caught and reported. Also if that props is, for example, an int, and you are trying to assign a String value to it, you will again be notified.
Second, wherever you use that function, Flash compiler will statically check if an instance of correct type charsys is passed into the function, so if there is no charsys or its subclass, a compilation error is thrown.
And third, this helps YOU to learn how to provide correct types for functions, and not rely on dynamic classes like MovieClip, which can have a property of nearly any name assigned to anything, and this property's existence is not checked at compile time, possibly introducing nasty bugs with NaNs appearing from nowhere, or some elements not being displayed, etc.
About common usage of such methods - they can indeed be used to create/manage a group of similar objects of one class, to the extent of altering every possible property of them based on their corresponding values. While default values for properties are occasionally needed, these functions can be used to slightly (or not so slightly) alter them based on extra information. For example, I have a function that generates a ready-to-place TextField object, complete with formatting and altered default settings (multiline=true etc), which is then aligned and placed as I need it to be. You cannot alter default values in the TextField class, so you can use such a function to tailor a new text field object to your needs.
Hope this helps.
This would work, I think I would assign values to the properties of the charsys object before passing it into the add method though, rather than passing the properties and having a different class do the property assignment. If you have some common properties they could either have defaults in charsys class definition or you could set literals in the addObj method.
Synopsis
How do you declare variables in a namespace while using the use statement? (ie., without declaring the namespace with the variable name)
How do you reference namespace variables with the "use" statement without a container reference. (ie., trace(foo) rather than trace(a.foo) [seems kinda pointless if I have to state this after already switching to the namespace])
Explanation
Having read Grant Skinner's "Complete Guide to Using Namespaces", and other articles, such as Jackson Dustan's "Better OOP Through Namespaces", I'm left with the above unanswered questions. I feel as though I'm missing some basic principle, but I can't seem to get namespaces to work. The following examples are written for use with the Flash IDE, so assume the following...
locus.as
package com.atriace {
public namespace locus = "atriace.com";
}
testA.as
package com.atriace {
public class testA {
import com.atriace.locus;
locus var foo:String = "Apple";
public function testA() {}
}
}
testB.as
package com.atriace {
public class testB {
import com.atriace.locus;
use namespace locus;
public function testB() {
trace(foo);
}
}
}
Document Class:
import com.atriace.testA;
import com.atriace.testB;
var a:testA = new testA();
trace(a.foo); // results in "Apple"
var b:testB = new testB(); // compile error: variable "foo" not defined.
Issue #1
In my mind, a namespace is little more than an object to hold variables that has scope level access. Ergo, global is a namespace visible to all functions (since it's the root scope), local is namespace (specific to the current and child scopes), and so on. If true, then switching to a namespace with use should allow you to simply declare variables that happen to exist in both the local and custom namespaces. For example:
use namespace locus
var bar:String = "test"; // this now *should* exist in both local & locus scope/namespace.
Since I'm unaware of a method to iterate over a namespace like a normal object, I don't know whether this is what happens. Furthermore, I haven't seen any cases where someone has declared a custom namespace variable this way, so I assume namespace variables must always be explicitly defined.
Issue #2
You might ask, "what's the goal here?" Quite simply, we want a dynamic pool of variables and methods that any new classes can add to (within the same package). By switching to this namespace prior to calling methods, we can reduce the wordiness of our code. So, class.method() becomes just method().
In testB.as we'd fully expect an error to occur if we never imported the testA.as class and instantiated it; especially because foo isn't a static member of the class (nor do we want it to be). However, since we've instantiated foo at least once, the namespace locus should now have a variable called foo, which means that when testB.as gets instantiated, and the constructor seeks a value for foo, the namespace already has one.
Obviously, there's a flaw in this thinking since the Flash compiler complains that foo has never been declared, and the only way I can reference foo from the document class is by referencing the container (ie., a.foo rather than just switching to the namespace with use, and tracing foo directly).
For the sake of argument, neither inheritance nor static members are a solution to this dilema. This is both an excercise in learning better code techniques, and an answer to the structure of a large utility class that has complicated dependencies. Given the absence of a variable/method, you could simply code around it.
I know it's not a heavily documented topic, which is why I'm hoping some sage here may see what I'm missing. The help would be much appreciated. :)
"use namespace" is for the consumer side. You always have to include the namespace in any declaration:
MyNamespace var foobar : uint;
If you wish to add namespaced package-global variables (you shouldn't as a general rule), you have to define each one of them in a separate .as file as packages only allow one publicly-visible definition per file at the top-level.
In your example above you are using namespaces incorrectly. A namespace can span multiple classes, but does not achieve the cross-class functionality you are looking for. This is more the domain of aspect-oriented programming.
Hi and thanks in advance,
I have a custom class being constructed from my main class. In the custom class it has another custom class that is passed in as a parameter. I would like to strictly type the parameter variable but when I do, 'the type is not a compile type constant etc'.
This, I understand, is because the custom class used as a parameter has not yet been constructed.
It all works when I use the variable type ( * ) to type the parameter.
I suspect this is a design flaw, in that I am using an incorrect design pattern. It is actually hand-me-down code, having received a large project from someone else who is not entirely familiar with oop concepts and design patterns.
I have considered using a dummy constructor for the parametered class in my main class but the passed in class also takes a custom class (itself with a parametered constructor). I am considering using ... (rest) so that the custom classes' parameters are optional.
Is there any other way to control the order of construction of classes? Would the rest variables work?
Thanks
(edit)
in main.as within the constructor or another function
var parameter1:customclass2;
customclass1(parameter1);
in customclass1 constructor:
public function customclass1(parameter1:customclass2)
{
....
Flash complains that the compiled type cannot be found when I use the data type customclass 2 in the paramater. It does not complain when I use the variable data type * or leave out the data type (which then defaults to * anyway). I reason that this is because customclass2 has not yet been constructed and is therefore not available to the compiler.
Alternatively, I have not added the path of customclass2 to the compiler but I am fairly certain I have ruled this out.
There are over 10,000 lines of code and the whole thing works very well. I am rewriting simply to optimise for the compiler - strict data typing, error handling, etc. If I find a situation where inheritance etc is available as an option then I'll use it but it is already divided into classes (at least in the main part). It is simply for my own peace of mind and to maintain a policy of strict data typing so that compiler optimization works more efficiently.
thnx
I have not added the path of customclass2 to the compiler but I am fairly certain I have ruled this out.
So if you don't have the class written anywhere what can the compiler do ? It is going to choke of course. You either have to write the CustomClass class file or just use "thing:Object" or "thing:Asteriks". It's not going to complain when you use the "*" class type because it could be anything an array, string, a previously declared class. But when you specify something that doesn't exists it will just choke, regardless of the order the parameters are declared in.
I think I've been using these terms interchangably / wrongly!
Iain, this is basically a terminology question and is, despite the "language-agnostic" tag associated with this question, very language/environment related.
For design discussions sake, property and instance variable can be used interchangeably, since the idea is that a property is a data item describing an object.
When talking about a specific language these two can be different. For example, in C# a property is actually a function that returns an object, while an instance variable is a non-static member variable of a class.
Hershi is right about this being language specific. But to add to the trail of language specific answers:
In python, an instance variable is an attribute of an instance, (generally) something that is referred to in the instance's dictionary. This is analogous to members or instance variables in Java, except everything is public.
Properties are shortcuts to getter/setter methods that look just like an instance variable. Thus, in the following class definition (modified from Guido's new style object manifesto):
class C(object):
def __init__(self):
self.y = 0
def getx(self):
if self.y < 0: return 0
else: return self.y
def setx(self, x):
self.y = x
x = property(getx, setx)
>>> z = C()
>>> z.x = -3
>>> print z.x
0
>>> print z.y
-3
>>> z.x = 5
>>> print z.x
5
>>> print z.y
5
y is an instance variable of z, x is a property. (In general, where a property is defined, there are some techniques used to obscure the associated instance variable so that other code doesn't directly access it.) The benefit of properties in python is that a designer doesn't have to go around pre-emptively encapsulating all instance variables, since future encapsulation by converting an instance variable to a property should not break any existing code (unless the code is taking advantage of loopholes your encapsulation is trying to fix, or relying on class inspection or some other meta-programming technique).
All this is a very long answer to say that at the design level, it's good to talk about properties. It is agnostic as to what type of encapsulation you may need to perform. I guess this principle isn't language agnostic, but does apply to languages beside python.
In objective c, a property is an instance variable which can take advantage of an overloaded dot operator to call its setter and getter. So my.food = "cheeseburger" is actually interpreted as [my setFood:"cheeseburger"]. This is another case where the definition is definitely not language agnostic because objective-c defines the #property keyword.
code example done in C#
public class ClassName
{
private string variable;
public string property
{
get{ return variable; }
set { variable = value; }
}
}
Maybe thats because you first came from C++ right?!
In my school days I had professors that said class properties or class atributes all the time. Since I moved to the Java C# world, I started hearing about members. Class members, instance members...
And then Properties apear! in Java and .NET. So I think its better for you to call it members. Wheather they are instance members (or as you called it instance variable) or class Members....
Cheers!
A property can, and I suppose mostly does, return an instance variable but it can do more. You could put logic in a property, aggregate values or update other instance variables etc. I think it is best to avoid doing so however. Logic should go into methods.
In Java we have something called JavaBeans Properties, but that is basically a instance variable that follows a certain naming pattern for its getter and setter.
At add to what has been said, in a langauge like C#, a property is essentially a get and set function. As a result, it can have custom logic that runs in addition to the getting/setting. An instance variable cannot do this.
A property is some sort of data associated with an object. For instance, a property of a circle is its diameter, and another is its area.
An instance variable is a piece of data that is stored within an object. It doesn't necessarily need to correspond directly with a property. For instance (heh), a circle may store its radius in an instance variable, and calculate its diameter and area based on that radius. All three are still properties, but only the radius is stored in an instance variable.
Some languages have the concept of "first class" properties. This means that to a client application, the property looks and is used like an instance variable. That is, instead of writing something like circle.getDiameter(), you would write circle.diameter, and instead of circle.setRadius(5), you would write circle.radius = 5.
In contrast to the other answers given, I do think that there is a useful distinction between member variables and properties that is language-agnostic.
The distinction is most apparent in component-oriented programming, which is useful anywhere, but easiest to understand in a graphical UI. In that context, I tend to think of the design-time configuration of a component as manipulating the "properties" of an object. For example, I choose the foreground and background colors, the border style, and font of a text input field by setting its properties. While these properties could be changed at runtime, they typically aren't. At runtime, a different set of variables, representing the content of the field, are much more likely to be read and written. I think of this information as the "state" of the component.
Why is this distinction useful? When creating an abstraction for wiring components together, usually only the "state" variables need to be exposed. Going back to the text field example, you might declare an interface that provides access to the current content. But the "properties" that control the look and feel of the component are only defined on a concrete implementation class.