I am not able to understand what is the difference between these two keywords in swift3?
If anyone has a link to a good article about this, please share.
There is no difference conceptually; moduleprivate was just a possible alternate name for the same access level that didn't get accepted during discussions about access control modifier naming.
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/013854.html
The internal modifier is the only one of the two that actually exists in the Swift language, but the two names represent the same behavior.
Related
Is there an updated list of Swift global functions? That is, functions that can be accessed from anywhere without the scope of a specific type, like max(),min(),dump(), zip(), sequence(), etc.
On the Apple docs the nearest link I found out is link, but it only refers min and max.
When building project documentation in docC by default all the global functions for a particular module are grouped under Functions section similar to Protocols section for protocols etc. Apple has customized this behavior so that global functions are grouped in different sections depending on their usage topic. Right now there is no way to list all of the global functions, you have to find them one by one manually. However, there is some work going on to implement fuzzy search on docC documentations to search using certain type of symbols etc.
I'm currently reading through Apple's "Intro to App Development with Swift" student guide. At the end-quiz of chapter 9, "Types", it asks:
When you're reading code and aren't sure of the type of a variable or constant, what's the quickest way to find out?
The answer is:
Rewrite the section of code using different encapsulation.
However, the concept of encapsulation has not been introduced before so I'm rather confused. In the e-book's Glossary, it states:
A language mechanism for restricting access to some of the object components and/or a language construct that facilitates the bundling of data with the methods of operating on that data.
Can anyone explain how this relates to finding out about the type of a variable or constant?
Thanks in advance.
The answer is:
Rewrite the section of code using different encapsulation.
That's a wrong answer. The right answer is "Use Xcode's [Quick Help] inspector."
Can anyone explain how this relates to finding out about the type of a variable or constant?
The suggestion here is that if you rewrite the source to make a private variable public (i.e. change the way it is encapsulated) it would make it easier to find the type of the variable in question.
It seems easy to find general info on a specific 'operator' (method, syntactic sugar), but I can't seem to find anything that has a list of all, or even just most, of these goodies. As such, it makes it fairly difficult, or at least overly time consuming, to work through learning the language.
I have already looked over this question. While it has great information, and definitely shows you how to find any information you need, I was hoping for something like a 'pocket ref' that just had all the relevant info and was only dedicated to that.
So, my question is this:
Is there a such a list?
Am I getting ahead of myself by looking for such a reference early on in learning the language?
Thanks in advance.
Well, a list of all operators makes as much sense as a list of all methods in the library, regardless of the type. It isn't going to be particularly useful except for finding information about a specific operator.
However, if you do want one, at any ScalaDoc site (http://www.scala-lang.org/api/current/ for the standard library) there is an alphabetic index just under the search bar. The first link (#) lists all the non-alphabetic methods (i.e. "operators").
Many of these are rarely used, or only in specific circumstances.
Obviously, any other library can introduce its own operators, and you'll need to check its own documentation.
I am doing another iOS application and I wonder if there are any naming conventions or good practices on how to name actions that I could follow. I am thinking of names on the functions that are invoked when user e.g. touches a button.
Go with Apple's guidelines. What were in the past good suggestions have now been codified in ARC (Automatic Reference Counting) and are necessary to be followed for ARC to generate correct code. Using these guidelines may well future-proof your code, it did for ARC!
Apple's guidelines
Coding Guidelines for Cocoa
From the method naming section:
Start the name with a lowercase letter and capitalize the first letter of embedded words. Don’t use prefixes.
There are two specific exceptions to these guidelines. You may begin a method name with a well-known acronym in uppercase (such as TIFF or PDF)), and you may use prefixes to group and identify private methods
For methods that represent actions an object takes, start the name with a verb.
- (void)invokeWithTarget:(id)target;
- (void)selectTabViewItem:(NSTabViewItem *)tabViewItem
Do not use “do” or “does” as part of the name because these auxiliary verbs rarely add meaning. Also, never use adverbs or adjectives before the verb.
If the method returns an attribute of the receiver, name the method after the attribute. The use of “get” is unnecessary, unless one or more values are returned indirectly.
- (NSSize)cellSize;
Use keywords before all arguments.
- (void)sendAction:(SEL)aSelector to:(id)anObject forAllCells:(BOOL)flag
Make the word before the argument describe the argument.
- (id)viewWithTag:(int)aTag;
I haven't come across much in the way of specifics when it comes to naming conventions for IBActions. However, if you were to follow the trend Apple seems to be setting in its sample apps, then some examples are as follows:
-(IBAction)cameraAction:(id)sender;
-(IBAction)done:(id)sender;
-(IBAction)takePhoto:(id)sender;
Hope this helps.
I guess any method name in Objective - C should be readable like you reading an english sentence. Lets say below method.
[fileWrapper writeToFile: path atomically: YES updateFilenames: YES];
// This is not a real example but purpose of sharing is to make sure
method name is readable, so programmers can actually read code and can
have SmallTalk.
When you read left to right it helps you to read and explains it self what it is going to do.
Check out this below link,
http://cocoadevcentral.com/articles/000082.php
Jump on page No. 5 of 7
There are lots of tips has been given. More tips can be found in Apple's developer library.
Happy Coding
Here is a discussion about how to name IBAction functions/methods.
Often when I create new classes, I first create a new interface. I name the methods of my interface exactly as I would like them to behave. A colleague of mine prefers to have these method names being more abstract, ie: areConditionsMet(). The reason, he wants to hide the 'implementation details'.
IMO implementation details are different from the expected behavior. Could anyone perhaps give more insight. My goal is to reach a common ground with my colleague.
Your method names should describe what the method does, but not how it does it. The example you gave is a pretty poor method name, but it's better than isXGreatherThan1AndLessThan6(). Without knowing the details about what it should do, I would say that it should be specific to the problem at hand, but general enough that the implementation could change without affecting the name itself, i.e., you don't want the name of the method to be brittle. An example might be isTemperatureWithinRange() - that describes what I'm checking but doesn't describe how it's accomplished. The user of the method should be confident that the output will reflect whether the temperature is within a certain range -- whether this is supplied as an argument or defined by the contract of the class, is immaterial.
Interfaces should represent some behavior or capability and not the way it is to be accomplished. Users of interfaces should not be interested in the way a target is achieved, they just want to know its done.
Implementation issues should not be included within the name of methods for that exact reason. The name of the table updated as a result of this method or the technology used has nothing to do in your domain object's method's name.
However from your question it is hard to say what is the exact case at hand.
If you could provide more details perhaps i could provide an additional help.
The names of your interface methods should leave the user of the interface in no doubt about what the method proposes to do from a functional perspective. If the implementation matches that, well and good.
Based on your updated comments:
Sounds to me like you need two methods: isModified() and hasProperties(). Leave it up to the user (or higher layer) of the domain object to determine if a particular criteria is fulfilled.
An interface should also be designed with the view that after it is released it will never be changed. By saying isDomainObjectModifiedAndHasProperties() you are setting in concrete that this is the criteria of fullfilment (regardless of any future unforseen implementation).