Skip to content
This repository has been archived by the owner on Jun 13, 2020. It is now read-only.

Allowing functions on primitives #716

Open
felixangell opened this issue Mar 1, 2016 · 19 comments
Open

Allowing functions on primitives #716

felixangell opened this issue Mar 1, 2016 · 19 comments

Comments

@felixangell
Copy link
Member

We were discussing this on the IRC, and me and sorta @kiljacken both agree that they could be really convenient. For instance in the string library, to compare a string the code is:

func compare(a: string, b: string) -> bool;

Which is used as follows:

compare(foo, bar);

This is okay, but it would be much cleaner to allow for having methods on primitive types for cleaner, flexible code:

func (a: string) compare(b: string) -> bool;

Which is used as:

foo.compare(bar);

There are some obvious flaws, most of which are relevant to the module system. Another thing I could picture being quite... strange is the following would technically be valid:

"foo".compare("bar");

Though we could disallow this behaviour with literals? I'm not sure about any other flaws, but if this feature is useful, then perhaps we could discuss either why it should not be implemented, or perhaps how we would resolve these flaws (without making huge changes to the compiler or language).

@SamTebbs33
Copy link
Contributor

Surely allowing this on literals isn't a bad thing?

@felixangell
Copy link
Member Author

Personally I think it's kind of inconsistent with the syntax, calling a function on literal just looks really strange. I'm not sure though, and I guess if others like it I can learn to live with it 😄

@SamTebbs33
Copy link
Contributor

I personally don't see any inconsistency. The function has to be called on some expression of type string, which "foo" is :)

@raoulvdberge
Copy link
Contributor

It's possible in Java I think? :p

@felixangell
Copy link
Member Author

@SamTebbs33 I mean inconsistency in the syntax more than the semantics of the language. In terms of the semantics its very consistent, though its kind of weird seeing a method being applied to a literal

@felixangell
Copy link
Member Author

@raoulvdberge I think so, but that's due to their weird generic thing

@raoulvdberge
Copy link
Contributor

It's weird indeed, but it's consistent at least.

@felixangell
Copy link
Member Author

Yeah, I don't mind if everyone thinks we should allow for it.

@felixangell
Copy link
Member Author

Paging @kiljacken & @MovingtoMars

@kiljacken
Copy link
Member

LGTM, the local methods on primitives will be a bit of work, but probably not that bad.

@SamTebbs33
Copy link
Contributor

@raoulvdberge @0xbadb002 Yeah it's possible in Java but not due to generics, it's just that because a string literal is an expression of type String, just like a string variable is of type String.

@felixangell
Copy link
Member Author

@SamTebbs33 Ah yeah, I was thinking they had some weird wrapper for every primitive for their generics or something.

@kiljacken What do you think on allowing calls on literals? "foo".compare("bar")?

@kiljacken
Copy link
Member

I said lgtm lol

On Wed, Mar 2, 2016, 17:34 Felix Angell [email protected] wrote:

@SamTebbs33 https://github.com/SamTebbs33 Ah yeah, I was thinking they
had some weird wrapper for every primitive for their generics or something.

@kiljacken https://github.com/kiljacken What do you think on allowing
calls on literals? "foo".compare("bar")?


Reply to this email directly or view it on GitHub
#716 (comment).

@felixangell
Copy link
Member Author

@kiljacken Oh, I thought that was generally on the concept 😛

@felixangell
Copy link
Member Author

I would say this is approved then, leaving this open for implementation.

@felixangell felixangell added this to the bootstrap milestone Mar 2, 2016
@MovingtoMars
Copy link
Member

I think we should only have methods on the string type.

@kiljacken
Copy link
Member

It's either for all or none of the primitives imo, the other will introduce even more special casing than just doing it for all the primitives.

@felixangell
Copy link
Member Author

Agreed, otherwise it becomes a weird obscure feature that has one use case and probably no one will use other than us for the standard library.

@MovingtoMars
Copy link
Member

I mean, we should define methods on string in the runtime, not allow defining arbitary methods on primitives (which would be hell for complexity. just use a normal function).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants