Need Explaining on the Double Label Function Declaration

Need explaining on the double label function declaration

Short answer: first argument label is for external caller, second one for local in-method use.

func moveBy(x deltaX: Double, y deltaY: Double) when calling looks following: moveBy(x: 1, y: 1), but inside the method deltaX and deltaY labels are used.

This naming style is not necessary, you can declare the method func moveBy(x: Double, y: Double) so x and y will be used inside the method.

To support legacy style, so from caller scope your method looks like moveBy(1, 1), you should place _ as first argument label: func moveBy(_ deltaX: Double, _ deltaY: Double). Such declarations are used in CocoaTouch to support legacy obj-c interface (ex. func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool).

labeled statement - incorrect definition?

The break must be literally nested inside the label. It's perfectly possible to call func from outside a labelled context, so break wouldn't refer to anything. The same goes for break and continue in reference to loops, they must be literally within the loop statement.

Put another way, a function must be a self-contained executable snippet. You must be able to look at a function and be able to tell what it does. break in that function doesn't obviously belong to any loop or label, it's nonsensical there. That meaning can't just be available at call-time, it must be available at time of declaration.

Why the onclick element will trigger twice for label element

When you click on the label, it triggers the click handler, and you get an alert.

But clicking on a label also automatically sends a click event to the associated input element, so this is treated as a click on the checkbox. Then event bubbling causes that click event to be triggered on the containing element, which is the label, so your handler is run again.

If you change your HTML to this, you won't get the double alert:

<input id="wowcb" type="checkbox" name="checkbox" value="value">
<label id="wow" for="wowcb">Text</label>

The label is now associated with the checkbox using the for attribute instead of wrapping around it.

DEMO

Haskell function seeking explanation

First: some formatting. This is how this code would typically be formatted in Haskell:

data BTree a = Empty 
             | Node (BTree a) a (BTree a)

labels :: BTree a -> [a]
labels Empty                   = [] 
labels (Node left label right) = labels left ++ [label] ++ labels right

reflect :: BTree a -> BTree a
reflect Empty                   = Empty 
reflect (Node left label right) = Node (reflect left) label (reflect right)

(Hint: if you indent code by 4 spaces it will show up properly syntax highlighted).
Now let's go through it:

data BTree a = Empty 
             | Node (BTree a) a (BTree a)

Defines a new 'parametric' data type. It is called parametric because of the small a which is a type parameter. This means that a can be replaced by any other type, for example Int, Double, String, or whatever. Think templates in C++ or generics in Java. Empty and Node are called the constructors of the data type. A BTree a can either be Empty or (that's what | symbolizes) contain a Node which contains a BTree a an a and another BTree a. The definition is recursive because the datatype (BTree a) shows up in its own definition.

labels :: BTree a -> [a]
labels Empty                   = [] 
labels (Node left label right) = labels left ++ [label] ++ labels right

labels collects all values that are contained in the tree. The first line is the type declaration: It takes a binary tree with a nodes (BTree a) and maps that to a list of as ([a]). The type alone already gives you a good idea of what might be going on.

The next two lines are what are called pattern matches. These are similar to case statements in other languages: you distinguish different possibilities and then choose the appropriate case (they are much more powerful though). You should note how they correspond exactly to the two constructors that BTree a has. If we are at an Empty node then we'll just return an empty list ([]). Otherwise we'll fall through to the next line and have a Node which must have a BTree a an a and a BTree a which we bind to left, label, and right. We might have called left, label and right whatever we wanted, but these are intuitive.

Now left and right are again of type BTree a so we can call labels on both and expect them to return a list of as, i.e. [a]. So labels is also recursive because it calls itself in its definition. This is a very powerful technique which is used a lot in Haskell. labels then concatenates the list it got from labels left, one which only contains the current label ([label]) and then one it got from labels right. So we can effectively conclude that it joins the labels from the left subtree with the current label and the ones from the right subtree and puts it all into a list.

reflect :: BTree a -> BTree a
reflect Empty                   = Empty 
reflect (Node left label right) = Node (reflect left) label (reflect right)

Works pretty much the same way as labels, except that it returns a tree of the labels and not a list. So effectively, this does nothing, it is a bit of an expensive identity function. But it is a template for something more powerful. For example, you could quite easily pass another function to reflect and apply it to each of its elements.

A function to set a value to a label

You can do that easily by passing label as reference ( I'm expecting label to be a double and not a string ) . Here is how

void setToValue(double &label , double value )
  {
    label = value;
  }

Note that you don't need to make the function as type double as it is not returning anything useful ( it would just be a waste ).

Or, you could do it like this

void setToValue(string &label,string value)
  {
    label = value;
  }

  int main()
   {
    string label;
    setToValue(label,"25.25");
    cout<<label;    
   }

When are argument labels required in Swift?

As of Swift 3.0 this has changed again: all methods, functions, and initializers require argument labels for all parameters, unless you have explicitly opted out using the external name _. This means methods such as addChildViewController(_:) are now written like this:

func addChildViewController(_ childController: UIViewController)

This was proposed and approved as part of the Swift Evolution process, and was implemented in SR-961.

Compiler error: Method with Objective-C selector conflicts with previous declaration with the same Objective-C selector

Objective-C does not support method overloading, you have to use a different method name. When you inherited UIViewController you inherited NSObject and made the class interopable to Obj-C. Swift on the other hand does support overloading, that's why it works when you remove the inheritance.

What do empty parentheses () after a function declaration do in javascript?

The code is defining an anonymous function (the (function (){ ... }) bit) and then calling it (with no arguments). It then assigns the value to the Browser property of the object that is presumably being defined outside of your code snippet.

You could also define the function somewhere:

function myFunction() {
    var ua = navigator.userAgent;
    var isOpera = Object.prototype.toString.call(window.opera) == '[object Opera]';
    return {
      IE:             !!window.attachEvent && !isOpera,
      Opera:          isOpera,
      WebKit:         ua.indexOf('AppleWebKit/') > -1,
      Gecko:          ua.indexOf('Gecko') > -1 && ua.indexOf('KHTML') === -1,
      MobileSafari:   /Apple.*Mobile.*Safari/.test(ua)
}

and then call it:

var foo = myFunction();

and then assign the value:

...
Browser: foo,
...

One downside with doing it that way is that you "pollute your namespace" with a function and a variable that you won't use anywhere else. The second issue is that you can't use the value of any locally-scoped variables in your function definition (the anonymous function behaves as a closure).

Argument labels for initialization parameters in Swift 3.1

The feature being described is this: Given a struct:

struct Point {
    let x: Double
    let y: Double
}

Swift will automatically generate Point.init(x: Double, y: Double). If you add an init method of your own in the main struct definition, then Swift won't create that automatic init. (If you add an init in an extension, then you will get an automatic init. This is why people often add convenience init in an extension for structs.)

The point the last paragraph is trying to make is that Point(x:y:) is preferable to Point(_:_:). The labels in an initializer are even more valuable than labels in method names, because all initializers have the same "base" name ("init"). They're just explaining why they didn't choose a more implicit default that some people might expect coming from other languages.

In short, sometimes unlabeled parameters make sense in methods depending on what the name of the method is and how unambiguous that makes the first parameter. But in init, unlabeled parameters should be eyed with strong suspicion.

---

Related Topics