In Java, I have an enum like:
public enum Toppings {
PEPPERONI,
EXTRA_CHEESE,
SECRET_SAUCE;
#Override
public String toString() {
switch(this) {
case EXTRA_CHEESE: return "Extra Cheese";
case SECRET_SAUCE: return "Secret Sauce™";
}
String name = name();
return name.charAt(0) + name.substring(1, name.length()).replace('_', ' ').toLowerCase();
}
}
I want to re-made this in Objective-C. So far, I've done this:
NS_ENUM(NSInteger, Toppings) {
PEPPERONI,
EXTRA_CHEESE,
SECRET_SAUCE
};
And then I was stumped. How would I make the toString() method? I know it's rather complex and uses some Java-specific behaviors, but I'm sure there's a way.
The only thing that comes to mind is to have a separate helper class with this functionality, but that seems a bit much, doesn't it?
Unfortunately, there is no way to add methods to an Objective-C enum. (Sidenote: you can add methods to a Swift enum.)
Traditionally, a standalone function would be used for this purpose, with a body similar to your Java method:
NSString* NSStringFromToppings(Toppings toppings)
{
switch (toppings)
{
case PEPPERONI: return #"Pepperoni";
case EXTRA_CHEESE: return #"Extra Cheese";
case SECRET_SAUCE: return #"Secret Sauce";
}
}
(Sidenote: you should name your enum Topping instead of Toppings--you can see how the code above would be clearer with a singular type name. You should also add a two- or three-letter prefix to all your type names (and this function) to avoid naming collisions.)
NSString * const ToppingsList[] = {
[PEPPERONI] = #"Pepperoni",
[EXTRA_CHEESE] = #"Extra Cheese",
[SECRET_SAUCE] = #"Secret Sauce",
};
NSLog("Topping: %#", ToppingList[PEPPERONI]);
After declaring your enum, you can add this to use type string. It seems like toString() method
EDIT: Meanwhile #andyvn22 is right. There is no way to add methods to enums in Objective-C. I just gave a solution for using enums with string.
Yeah, it's not as straightforward as in, say, Java or .NET. However, I think that option 2 of yar1vn's answer looks ok:
Convert objective-c typedef to its string equivalent
You could also add enum serialization as an NSString extension, making it possible to ask NSString to give you a string based on your enum.
No, there is no way to declare a method in an enum using Objective-C.
However, you can use an enum as a parameter to any method. This might be a solution for you:
typedef NS_ENUM(int, PatientActivity)
{
Exercise = 101,
Smoke,
Alcohol
};
- (void)getPatientDetail:(NSString *)PatID withActivity:(enum PatientActivity) activity;
Related
When writing this example into the IDE:
enum class EnumTest {
FOO, BAR;
lateinit var foobar: String
}
I get the message With old Native GC, variable in enum class can't be changed after initialization on the "foobar" variable. I can't find anything about this message online. Also everything seems to work just fine, so my question is:
When and how does this affect me?
Thank you!
You could declare your values in a singleton object, set them there and reference it in the enum.
object Constants {
var FOO_STR = "bla"
var BAR_STR = "bar"
}
enum class EnumTest(val foobar: String) {
FOO(Constants.FOO_STR),
BAR(Constants.BAR_STR);
}
This code should work but also smells fishy.
Since an enum has an immutable flavor by design, I would not recommend this approach. I feel bad about posting this... but if your main problem is the resource heavy loading of these constants, maybe you do not need an enum to store those properties. Maybe just think of a simple singleton container with simple (named) properties.
I've been starting to use VS2017 Community. This bugs me:
Below is normal getter setter from previous VS:
public string Name
{
get{ return _name;}
set{ _name = value;}
}
This is the new getter setter:
public string Name { get => _name; set => _name = value; }
Anyone can explain to me why the syntax is changed?
I wouldn't say they changed it, I would say they gave us some new syntax options. You can still use the "old" way of declaring getters and setters, but there is now also a more functional programming style of doing it as well. In C#6 Microsoft already introduced using expressions for getter only properties doing:
public int SomeProp => someMethod();
C#7 enhanced this support allowing it to be used for getters AND setters. One nice feature of this is with the new "throw expressions" feature which allows us to make some concise syntax. For example, before you had to do.
private string _name;
public string Name
{
get
{
return _name;
}
set
{
if (value == null)
throw new ArgumentNullException(nameof(Name));
_name = value;
}
}
We can now simplify this to:
private string _name;
public string Name {
get => _name;
set => _name = value ?? throw new ArgumentNullException(nameof(Name));
}
Granted, you could do the throw expression even without making the setter a lambda, but as you can see, for simple things, it makes the syntax very concise.
As with anything, use the syntax that makes the most sense to you and is most readable for the people who will be coding your application. Microsoft has been making a push to add more and more functional programming style features to C# and this is just another example of that. If you find it ugly/confusing/not needed, you can absolutely accomplish everything you need with the existing method. As another example, why do we have while and do while loops? I can honestly say I've used a do while loop maybe 5 times in my career. A while loop can do everything a do while can just with different syntax. However, there are sometimes where you realize that using a do while will make your code more readable, so why not use it if it makes things easier to follow?
The syntax hasn't changed: it has been improved. C# has been always backwards-compatible with syntax and grammar from previous versions.
Why property getters/setters can be implemented with lambda syntax (expression-bodied accessors)? Probably there's no scientific reason to do so, but there's a consensus about introducing useful functional programming constructs in C# as it turns the language into a more productive tool.
Just foillow up C#'s evolution since C# 2.0:
From delegates provided as regular methods to anonymous delegates.
LINQ, lambda-style delegates/expression trees.
Expression-bodied methods.
...and expression-bodied accessors! And probably future C# versions will introduce even more functional programming-style syntax and grammar.
You'll notice they removed the 'return' syntax, this was done (from what I've read) to make it more clear that they aren't functions (and when reflected can't be treated as functions and can't be made into delegates) but rather this kind of 'pseudo-function' (if you get what I'm trying to well get at).
So basically its to make it more clear that the getter is linking this this variable and the repeating for the setter. It also is because in newer versions you can do something like
public int MyInt => x ? y:z;
Which represents
public int MyInt
{
get
{
return x ? y:z;
}
}
Also both syntax should work, its just a new syntax that they added to bring it in line with the above example.
I know I am adding this details after a year, but just understood that my VS 2017 generated new syntax on my web user control, and that does not reflect on the aspx file when I wanted to set a value for it.
like
private bool _ShowBankDetailPanel = false; //To Show Bank details section in registration
public bool ShowBankDetailPanel { get => _ShowBankDetailPanel; set => _ShowBankDetailPanel = value; }
and on ASPX side you will NOT have property like
it is only recognize
old style getter setter....(I experience this,,, but I am be wrong)
I am writing an OS X/iOS framework in Objective-C, and I would like for the framework to be useful for developers using either Objective-C or Swift.
In normal Objective-C enums are defined like this (this example is taken directly from Apple's own UIView class reference).
typedef enum {
UIViewAnimationCurveEaseInOut,
UIViewAnimationCurveEaseIn,
UIViewAnimationCurveEaseOut,
UIViewAnimationCurveLinear
} UIViewAnimationCurve;
To make this enum Swift-friendly, my understanding is that it should be declared like this.
typedef NS_ENUM(NSInteger, UIViewAnimationCurve) {
UIViewAnimationCurve_EaseInOut,
UIViewAnimationCurve_EaseIn,
UIViewAnimationCurve_EaseOut,
UIViewAnimationCurve_Linear
};
This allows the enum to be accessed in the style of let curve: UIViewAnimationCurve = .EaseInOut from Swift.
My problem is that the NS_ENUM and underscore method produces strangely named enums when used from Objective-C. The NS_ENUM method allows dot notation to be used from Swift, but it also means that any ObjC code will need to use an underscore in the enumerated name, which is undesirable.
How can I allow dot notation for Swift while still preserving Objective-C style naming conventions for within ObjC code?
You simply follow the usual convention – no underscoring is necessary. Swift compiler is smart enough to just cut the common prefix out (the part that matches the enum type name). You do have to use an NS_ENUM for the enum to be made visible to Swift, but it's good practice anyway.
Case in point, for instance UIViewAnimationCurve is defined in an Objective-C header in just the form you describe in your first code example and works just fine in Swift:
If you define it like this:
typedef long TrafficLightColor NS_TYPED_ENUM;
TrafficLightColor const TrafficLightColorRed;
TrafficLightColor const TrafficLightColorYellow;
TrafficLightColor const TrafficLightColorGreen;
if get compiled to swift like this:
struct TrafficLightColor: RawRepresentable, Equatable, Hashable {
typealias RawValue = Int
init(rawValue: RawValue)
var rawValue: RawValue { get }
static var red: TrafficLightColor { get }
static var yellow: TrafficLightColor { get }
static var green: TrafficLightColor { get }
}
Looks like what you need, anyway take a look at: https://itunes.apple.com/us/book/using-swift-with-cocoa-and-objective-c-swift-4-1-beta/id1002624212?mt=11
Working through The Swift Programming Language, I was surprised to see that, unlike structures and enumerations, classes do not support stored type properties.
This is a common feature of other OO languages so I assume there was a good reason they decided not to allow it. But I'm not able to guess what that reason is, especially since structures (and enumerations) have them.
Is it simply that it's early times for Swift and it just hasn't been implemented yet? Or is there a deeper reason behind language design decision?
BTW, "stored type property" is Swift terminology. In other languages these might be called class variables. Example code:
struct FooStruct {
static var storedTypeProp = "struct stored property is OK"
}
FooStruct.storedTypeProp // evaluates to "struct stored property is OK"
class FooClass {
class var computedClassProp: String { return "computed class property is OK" }
// class var storedClassProp = "class property not OK" // this won't compile
}
FooClass.computedClassProp // evaluates to "computed class property is OK"
Edit:
I now realize this limitation is trivial to work around, e.g., by using a nested structure with stored properties:
class Foo {
struct Stored {
static var prop1 = "a stored prop"
}
}
Foo.Stored.prop1 // evaluates to "a stored prop"
Foo.Stored.prop1 = "new value"
Foo.Stored.prop1 // evaluates to "new value"
That seems to preclude their being some deep inscrutable language design reason for this limitation.
Given that and the wording of the compiler message that Martin Gordon mentions, I have to conclude that this is simply something (minor) left out.
The compiler error is "Class variables not yet supported" so it seems like they just haven't implemented it yet.
Extending the OP's nested struct trick for simulating stored type properties, you can go further and make it look like a pure stored type property from outside the class.
Use a computed getter and setter pair like:
class ClassWithTypeProperty
{
struct StoredTypeProperties
{
static var aTypeProperty: String = "hello world"
}
class var aTypeProperty: String
{
get { return self.StoredTypeProperties.aTypeProperty }
set { self.StoredTypeProperties.aTypeProperty = newValue }
}
}
Then you can do:
println(ClassWithTypeProperty.aTypeProperty)
// Prints "hello world"
ClassWithTypeProperty.aTypeProperty = "goodbye cruel world"
println(ClassWithTypeProperty.aTypeProperty)
// Prints "goodbye cruel world"
“For value types (that is, structures and enumerations), you can define stored and computed type properties. For classes, you can define computed type properties only."
Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/cn/jEUH0.l
I think it's easy for Apple's Engineers to add stored type properties to classes, but not yet we know, maybe never in my opinion. And that's why there are labels ( static and class ) to distinguish them.
The most important reason may be it:
To avoid different objects have shared changeable variable
we know :
static let storedTypeProperty = "StringSample" // in struct or enum ...
can be replaced by
class var storedTypeProperty:String {return "StringSample" } // in class
but
static var storedTypeProperty = "StringSample"
is harder to be replaced by class phrase in class.
// I am new to Swift Programming Language actually and it's my first answer in Stack OverFlow. Glad to discuss with you. ^^
So I've run into a case where I have a class that can store either a string or a numeric value, and I want a single property to return one or the other (it would be a failure for both to be set). I'm using a custom generic class to deal with the numerics (so I can use signed, unsigned, and nullables), and will be storing the string in a separate variable.
In theory, if overloading could be done based on the return type, I could do this quite easily. But .NET currently disallows this. So I am wondering if there is some other really-far-out-there trick (outside of MSIL generation via Reflection.Emit) that could accomplish the same thing.
I'm open to ideas via delegates, pointer dereferencing, generics, mystical rites, etc. Also interested in any thoughts or pros/cons of such possibilities as a learning tool. If using a standard Object is the only way to achieve what I want, then that's fine with me. But It's difficult to find the correct set of keywords to hunt down this kind of capability on Google, so I thought I'd ask here before I moved on to doing something else on the project.
I don't see how using anything other than Object would work, for a simple property. Imagine you're the caller - what would you expect the declared type of the property to be? What type of value would you try to assign the expression to?
If you really have to have a single property which can return various different types, Object sounds like the way to go.
You can have the public property as string and also return the number after converting it to string.
public string YourProperty
{
get {
if(somecondition)
return "some string";
else if(someothercondition)
return 1234.ToString();
}
}
while accessing your property you can use Convert.ToInt32().
Example:
public void YourMethod()
{
int a;
string str;
bool isNumber;
try
{
a = Convert.ToInt32(obj.YourProperty);
isNumber = true;
}
catch(FormatException e)
{
str = obj.YourProperty;
isNumber = false;
}
}
Though this is not a good way programming, but you will acheive your objective of using only one property for both string and number.