Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should object method param names be equal in declaration and definition? #124

Closed
pubudu91 opened this issue May 15, 2019 · 14 comments
Closed
Assignees
Labels
Area/Lang Relates to the Ballerina language specification spec/unclear Spec does not clearly explain the design
Milestone

Comments

@pubudu91
Copy link

pubudu91 commented May 15, 2019

If we consider an object, should the parameter names of a method declaration be equal to their corresponding counterparts in the method definitions?

type Foo object {
    function print(string value);
};

function Foo.print(string v) {
    
}

The spec doesn't specify whether the param names are significant in this case.

Somewhat related to #125 as well

@jclark
Copy link
Collaborator

jclark commented May 15, 2019

There is no logical need for them to be the same, but it would probably reduce confusion to require this. @sanjiva what do you think?

@sanjiva
Copy link
Contributor

sanjiva commented May 15, 2019

We should require them to be the same - otherwise its lots of unnecessary confusion.

@pubudu91
Copy link
Author

Ack. Will keep the same name for both.

@jclark
Copy link
Collaborator

jclark commented May 16, 2019

@sanjiva Also need to decide whether annotations are required to be the same for both.

@sanjiva
Copy link
Contributor

sanjiva commented May 16, 2019

No I think annotations have to be different I think .. and we union the annotations.

(That raises an interesting question whether annotation order matters .. new issue?)

@jclark
Copy link
Collaborator

jclark commented May 16, 2019

I don't think they should be union-ed. A user who wants to make use of the object type should only have to read the object type declaration, and should not need to look at the outside method implementations. If you don't want to repeat, then I think the annotations relating to the function type should be on the declaration only. Annotations on extern could of course on the definition.

@jclark jclark reopened this May 16, 2019
@sanjiva
Copy link
Contributor

sanjiva commented May 16, 2019

Hmm that means there's a semantic difference between

object A {
  @x:y { }
  function foo () { .. }
}

and

object A {
  function foo ();
}

@x:y { }
function A.foo () { .. }

I'm not sure that's good.

Also, didn't understand Annotations on extern could of course on the definition. If you meant "could be on the definition" then I don't know what that means ... extern means not implemented in B7a. So where would B7a annotations go?

@jclark jclark added the Area/Lang Relates to the Ballerina language specification label May 16, 2019
@jclark jclark added this to the 2019R2 milestone May 16, 2019
@jclark jclark added the status/discuss Needs discussion outside github comments label May 16, 2019
@sameerajayasoma
Copy link
Contributor

AFAIU, What @jclark meant to say is the following.

object A {
  @x:y { }
  function foo ();
}

@java {class:"", method:"" }
function A.foo () = external

This can confuse a mort. Figuring out what annotations go on the declaration and what annotations go on the definition is not straightforward IMO.

@sameerajayasoma
Copy link
Contributor

sameerajayasoma commented May 16, 2019

Should we also define which documentation string takes the precedence? It is logical to say that documentation should be specified on the method declaration.

@jclark
Copy link
Collaborator

jclark commented May 17, 2019

The @java annotation should be on the external

@jclark
Copy link
Collaborator

jclark commented May 29, 2019

This also relates to parameter names being optional, which was issue #148.

@sanjiva
Copy link
Contributor

sanjiva commented May 30, 2019

All of this my poor Mort-mind-blowing aspects can be avoided if we lose outside methods and just say methods have to defined, not just declared, in the object itself.

I guess that ship has sailed already :).

In that case I think we should just require everything that is being repeated (function name (duh), param names, modifiers) to be the same and for other metadata (docs, annotations) to be in declaration in the object. If anything is specific to the implementation (e.g. annotation related to '= external') then that can be on the definition, not decl.

@jclark jclark mentioned this issue May 31, 2019
@jclark
Copy link
Collaborator

jclark commented Jun 2, 2019

Conclusion after discussion today was that we should consider removing the outside method definition feature. See issue #179.

@jclark jclark added spec/unclear Spec does not clearly explain the design and removed status/discuss Needs discussion outside github comments labels Jun 2, 2019
@jclark jclark self-assigned this Jun 4, 2019
@jclark
Copy link
Collaborator

jclark commented Jun 4, 2019

Since we decided to remove the outside method definition feature, this issue no longer arises.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area/Lang Relates to the Ballerina language specification spec/unclear Spec does not clearly explain the design
Projects
None yet
Development

No branches or pull requests

4 participants