When I try to create Extension Function to set Boolean true or false like the below.
Boolean.setTrue(){
this = true
}
Boolean.setFalse(){
this = false
}
It says variable expected. How to achieve this.
You cannot change the value of this, this would break a lot of assumptions, even if you could you would not be able to change the value, as Booleans are immutable.
More generally, there is a fine line between simplifying code, and making it more complex, and in this case that would complicate it. I would agree that adding String.splitByDot() may make sense, but replacing idiomatic code tends to just make the code more complex, as you start to wonder why the code had to be replaced.
Sorry but this does not make sense. Just use myBool=false, it's what anyone understands and cannot get any more readable.
Also Boolean is immutable and what you're trying isn't possible anyways.
We have to be careful not to overuse extensions. It's one of the greatest features Kotlin (and others) offers, but in certain examples, e.g. trying to change the way a dead simple Boolean is being assigned, it's getting dangerous IMHO (luckily it's not possible).
Here is an extension method that works in C# 7.2 or later:
public static class Extensions
{
public static bool Toggle(ref this bool b) => b = !b;
}
Then elsewhere, something like this will work:
bool b1 = true; // Works for primitive bool type.
Boolean b2 = true; // Works for Boolean object, too.
b1.Toggle();
b2.Toggle();
The only benefit I see to using an extension method is to shorten lines with long bool expressions, such as replacing:
this.SomeObjectWithALongName.SomeVerboselyNamedProperty
= !this.SomeObjectWithALongName.SomeVerboselyNamedProperty
with
this.SomeObjectWithALongName.SomeVerboselyNamedProperty.Toggle();
I don't know what drawbacks this extension method may have.
The reason you can't do this is that you cannot reassign the receiver in an extension function.
It's not possible to change the value of the Boolean because it is immutable.
The reason you can do this comes to a lack of implementation of Kotlin extension probably due to the fact Extension in Kotlin are resolved Statically (even probably really static).
So 'this' in a static context doesn't make sense.
Related
Here is a little background:
I am trying to test some functions. I CANNOT change anything in the function or any class variables.
So I am calling this function in my unit test, the problem is that, there is a boolean flag, this method simply will just not execute if this flag is not set to true. But this flag has a private setter, so I can directly set it.
I asked around someone told me to use a extension IN the test file to set the variable, but I've tried I don't think I can set it if the extension is not in the same file as the function. Am I doing something wrong? Or is there any other way to test it?
What they were referring to is to place an extension in the file with the class-under-test. So if you have something like:
class ToBeTested {
private(set) var bool: Bool
}
You can add an internal setter:
extension ToBeTested {
func setBoolTrue() { bool = true }
}
But this has to be in the same file with ToBeTested. If you cannot modify that file, this is not a solvable problem. If it needs to be tested this way, then the class will need to be designed to permit that.
When a property is marked private(set), the compiler can assume that the value cannot be changed in any way outside this file. That allows it to apply optimizations that may not be valid if the property were changeable outside this file. The "setter method" may not even exist if the compiler determines that it doesn't need it. For example, it may completely inline that operation, or eliminate it entirely if it can prove the value is never changed.
Is this code wrong, or is this a known issue?
final class Foo {
//#inlinable #inline(_always)
static func bar(_ first: String = "default", _ second: Int) {
print(first,second)
}
}
Foo.bar(2)
Will result:
I don’t find this surprising in the way that some of the comments do. Arguments must always be supplied in order. In the total absence of labels, the only valid way to do that is to supply the first argument or both. Supplying a single argument thus means you need to supply a string. The default value doesn’t change any of that.
The error message is unhelpful as usual, and other languages may behave differently, but that doesn’t constitute a bug. If there’s anything to complain of, it’s that the compiler should have warned against the original method declaration, as the default value for the first parameter is otiose.
I would not say it is a bug more likely it is a feature. This code smells really bad codestyle...
You don't specify the names for the parameter which can lead to really bad things and assigning Int to String... I wouldn't be surprised
Now I don't wanna "educate" you how to write nice code, but the example you posted above really is not. It is just not very intuitive to write functions without label, this is perfect example why we should be using labels... Writing functions as suggested by Swift community works just awesome...
final class Foo {
//#inlinable #inline(_always)
static func bar(first: String = "default", second: Int) {
print(first,second)
}
}
Foo.bar(second: 2)
Why not just omit the underscores? :)
Which method should I implement in Xtend if I want to declare equality check?
AFAIK if I use '==' operator, then it gets compiled as equals() call in Java.
If so, then why would I define an operator_equals() when I can simply override equals()?
UPDATE: As #kapex pointed out it is not recommended to override '==' as it can lead to code behaving differently in Xtend and Java, sample below:
class Person {
override equals(Object person) {
true // We are all the same
}
def operator_equals(Person person) {
false // We are all different
}
}
If your goal is to change "equal to" behavior, then you should simply override equals (and hashCode).
You would only define operator_equals if you want it to have different behavior than equals. But you generally wouldn't want that.
If you overload the == operator, the original equals method still exist and some some code might use the operator while other code will use equals (for example Java libraries). This sounds like a good way to break something.
It makes sense for Xtend to provide the ability to overload all operators for some odd use cases or even just for consistency, but in my opinion redefining existing operator behavior is bad practice and should be avoided. It's much safer to only overload operators that are not yet defined for a type.
I have an application where some var values ought to be published to a message queue on change. That is, if a var's setter is invoked I want this to be noticed somehow and after setting the new value I want it to be published to the MQ.
I did something like this some time ago with Perl/Moose by setting an after-modifier (doing the publishing) on methods with a certain method attribute. That solution was very elegant and required no syntactical overhead besides the additional method attribute.
What would be a good solution using Scala's (2.10) capabilities without using clumsy OO patterns?
Update: What I would like to achieve is that the code looks something like this:
#Publishable var someProperty = 42
or
domainSpecificLanguageMagic someProperty = 42
One of the challenges is that these properties might be reflectively set, so a setter-method with a different name is (probably?) not an option.
I guess the way to go is scala virtualized: it has some built in primitives that allow you to change language semantic including assignment one. It isn't stock scala , but it is quite officially supported and new release usually comes no too late after the ordinary one (in a matter of weeks). (I'm confused it with another scala framework -- LMS, AFAIS it isn't supported quite good ATM, but still should solve your problem)
You can make the property private (and give it a variant name) and define its accessor and mutator methods:
class C1(...) {
private var iProp: Int = 0
def prop: Int = iProp
/* Put additional logic associated with mutation here: */
def prop_=(newProp: Int): Unit = iProp = newProp
}
The documentation says this is allowed:
ClassMethod GetContacts() As %ListOfObjects(ELEMENTTYPE="ContactDB.Contact")
[WebMethod]
I want to do this:
Property Permissions As %ListOfObjects(ELEMENTTYPE="MyPackage.MyClass");
I get an error:
ERROR #5480: Property parameter not declared:
MyPackage.Myclass:ELEMENTTYPE
So, do I really have to create a new class and set the ELEMENTTYPE parameter in it for each list I need?
Correct syntax for %ListOfObjects in properties is this one
Property Permissions As list of MyPackage.MyClass;
Yes, a property does sometimes work differently than a method when it comes to types. That is an issue here, in that you can set a class parameter of the return value of a method declaration in a straightforward way, but that doesn't always work for class parameters on the class of a property.
I don't think the way it does work is documented completely, but here are some of my observations:
You can put in class parameters on a property if the type of the property is a data-type (which are often treated differently than objects).
If you look at the %XML.Adaptor class it has the keyword assignment statement
PropertyClass = %XML.PropertyParameters
This appears to add its parameters to all the properties of the class that declares it as its PropertyClass. This appears to be an example of Intersystems wanting to implement something (an XML adaptor) and realizing the implementation of objects didn't provide it cleanly, so they hacked something new into the class compiler. I can't really find much documentation so it isn't clear if its considered a usable API or an implementation detail subject to breakage.
You might be able to hack something this way - I've never tried anything similar.
A possibly simpler work around might be to initialize the Permissions property in %OnNew and %OnOpen. You will probably want a zero element array at that point anyway, rather than a null.
If you look at the implementation of %ListOfObjects you can see that the class parameter which you are trying to set simply provides a default value for the ElementType property. So after you create an instance of %ListOfObjects you could just set it's ElementType property to the proper element type.
This is a bit annoying, because you have to remember to do it every time by hand, and you might forget. Or a maintainer down the road might not now to do it.
You might hope to maybe make it a little less annoying by creating a generator method that initializes all your properties that need it. This would be easy if Intersystems had some decent system of annotating properties with arbitrary values (so you could know what ElementType to use for each property). But they don't, so you would have to do something like roll your own annotations using an XData block or a class method. This probably isn't worth it unless you have more use cases for annotations than just this one, so I would just do it by hand until that happens, if it ever does.