Kotlin: why do constructor parameters have "internal" visibility by default? - constructor

If we have a class:
class Customer(val customerName: String) { }
Its contructor parameter customerName is accessible through getCustomerName() (because it's also a property). If we want to restrict access to this property we should declare it as private.
Since in many cases from Java world (and if a class is not intended to be data class) fields which are assigned from constructor parameters are for private / protected use it feels like an additional effort to explicitely declare them private in Kotlin.
Also, Kotlin classes are final by default, so why not follow this principle for properties? Am I missing something?

In our experience, and from some empirical studies of existing codebases, internal/public visibility is best for properties.
Also, Kotlin classes are final by default, so why not follow this principle for properties? Am I missing something?
Properties are final by default, i.e. they can not be overridden unless you supply the open modifier explicitly.

A Protected Modifier in Kotlin: CANNOT be set on top-level declarations. Declarations that are protected in a class, can be accessed only in their subclasses.
for more details you can use this link

Related

How to write a wrapper class / Override configuration in pre existing Puppet Class

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.

how to add annotations to method/constructor parameters without touching the source code?

I am trying to de/seralize framework objects (no source code access) into JSON using jackson 2.
class Item {
public Item(Long id) {}
}
I found this Add annotation to a parameter on a new method created with Javassist but this solution is based on JavaAssist and does not fully apply :(
The underlying issue is the lack of DefaultConstructors which can be solved using the #JsonCreator annotation together with a matching #JsonProperty annotation for the parameter.
#JsonCreator
class Item {
public Item(#JsonProperty("id") Long id) {}
}
I managed to achieve this for one of the many item subclasses using a mixin class.
public abstract class ItemChildMixin {
#JsonCreator
public ItemChildMixin(#JsonProperty("objId") final Long objId) {
}
}
However, writing mixin classes for all the relevant objects with almost the same content seems the wrong approach, so I started looking at aspects.
Adding the Annotation to the classes in the Item's hierarchy was easy:
aspect DeclareJsonCreatorAspect {
declare #constructor: Item+.new(Long): #JsonCreator;
}
However, I cannot seem to find a way to add an annotation to the constructor parameters using Aspects!
Aspectj in Action as well as google did not provide an answer yet.
Is this at all possible?
Currently AFAIK AspectJ (currently v1.8.4) is unable to deal with annotations on method parameters, be it in pointcuts or in ITD (inter-type definition) statements.
I am sorry that I do not have any better news, but this is the status quo. If you have a chance to declare whole methods via ITD you can influence the full signature, but adding parameter annotations on existing methods is impossible today. You might also be able to also declare default constructors via ITD, if that helps. I am pretty sure there is a way to achieve what you want, just maybe not the way you imagine.

Naming conflict: Same method name in inherited class and interface

public class A extends B implements C {
}
Class B and interface C have the same member function name(not the same signature).
This code can't be compiled. How can I solve this?
The inherited class implements your interface method, so there should not be an error. In fact, both having the same name is really the idea of implementing an interface...
Here's a check list:
The method must have not only the same name, but the same signature. Make sure you've specified the correct argument and return types (this includes initial values).
If your sub class A also implements the same method, you must mark it as override. Same rules apply regarding the signature.
If you do override B's method, it must not be declared final.
If your class does not have the exact same method name AND signature, it is not properly implementing your interface. That's the long and short of it. You can either remove the implementation or change the method signature to fix it.

Is there any use for a private constant, that is not static?

Is there any reason to have a private constant, that is not static? Are there any situations that you would need a non-static private const? Would it make sense if constants where static by default?
I use ActionScript3 and some Java, but I think this is a broader OOP question.
I don't know if this counts, but in Java you need to make local variables final to be able to use them in inner classes (because Java has no real closures, and instead makes copies of the captured scope, which must henceforth be immutable):
void test(){
final long startTime = System.currentTimeMillis(); // needs to be final
new Runnable(){
System.out.println(startTime);
}.run();
}
Also, you can make fields and variables final in order to protect yourself from accidentally re-assigning them (and the compiler and runtime may also use this information for performance optimizations).
Of course, both of these examples are not really about constants in the mathematical sense (final variables in Java can be assigned to computed expressions depending on variable input).
Another reason other than the accessing the variable in the anonymous class (like Thilo said) is if you want an object that you can't change the assignment of, but it maintains some state of the current object, and thus you can't share it among multiple instances of the class.
C# has this concept of readonly fields i.e. fields that can only be assigned in the constructor and cannot be changed in any other method. They are like constants for a specific instance of a class (outside its constructor) rather than for the class itself.

AS3: should private variables have an _

I thought that AS3 now has private abilities added. So why should I still preface private variables with an underscore?
private var _privVar:String;
I make it a general rule in ActionScript 3 to follow Adobe's style.
Don't use underscores for private varibles unless your using a getter or setter. For example:
private var _foo:String;
public function get foo():String
{
return _foo;
}
public function set foo(value:String):void
{
_foo = value;
}
This example getter/setter is a little useless, as you could just make a public property that does the same thing. Only use a getter or setter when you need to do something special when you get or set the property. Even then, it's usually best just to create a public method instead.
Also another point. Personally I don't think it's a good idea to abbreviate your variable or method names. So instead of calling my variable privVar, I would call it privateVariable. This is especially true if you are using an IDE with autocomplete/suggest such as FlashBuilder(Flex Builder) or FlashDevelop.
Take a look at Adobe - coding conventions and best practices for more information.
You don't have to. It's something that encourages readability, but is by no means mandatory. Entirely a personal preference.
Using an underscore is just a convention. And I try to avoid them because it messes with my intellisense. I'm used to typing obj.va and hitting ctrl-space in flex builder to get obj.variableName - this doesn't work well with _variableName
Btw, does earlier versions of ActionScript require you to preface "private" variable names with an underscore?
I think that you shouldn't abbreviate variables. it hardens readability and auto completion. On the other hand in my practice it's not a good thing to use built-in AS getters and setters with a syntax of function set someVar ( value ) : void. It hardens refactoring very much because when get in many time by just not knowing that some variable is a setter or getter.
In where I used to work we used Java Beans property access convention like function setSomeVar ( value ) : void. Of course, because it's not a common use in AS community, such IDE's like FlashDevelop doen't support such getters and setters generation.