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

Functions with class-specific modifiers are allowed in global scope #797

Closed
alexnask opened this Issue Aug 18, 2014 · 15 comments

Comments

Projects
None yet
3 participants
@alexnask
Collaborator

alexnask commented Aug 18, 2014

For example

f: abstract func { "test" println() }
f()

Compiles and runs fine.
Should this be allowed behavior?
I'm tagging this as bug because I think it is not expected behavior, can you confirm @fasterthanlime ?

Edit:
Here is one more example with the three modifiers that should be disallowed

f: abstract func

g: static func

h: final func

@alexnask alexnask added Bug labels Aug 18, 2014

@alexnask alexnask self-assigned this Aug 18, 2014

@fasterthanlime

This comment has been minimized.

Collaborator

fasterthanlime commented Aug 18, 2014

Definitely not expected behavior, nonsensical modifiers should err outside
of class declarations.

On Mon, Aug 18, 2014 at 2:50 PM, Alexandros Naskos <notifications@github.com

wrote:

For example

f: abstract func { "test" println() }f()

Compiles and runs fine.

Should this be allowed behavior?
I'm tagging this as bug because I think it is not expected behavior, can
you confirm @fasterthanlime https://github.com/fasterthanlime ?


Reply to this email directly or view it on GitHub
#797.

@alexnask

This comment has been minimized.

Collaborator

alexnask commented Aug 18, 2014

Ok, I'm on to it next after implementing abstract operators :)

@alexnask alexnask changed the title from Abstract functions are allowed in the global scope to Functions with class-specific modifiers are allowed in global scope Aug 18, 2014

@alexnask alexnask added Front-end and removed Middle-end labels Aug 18, 2014

@alexnask

This comment has been minimized.

Collaborator

alexnask commented Aug 18, 2014

I've fixed this but on a branch that sits on top of the abstract operator changes, so I'm waiting for code review on that pull request before I open this one :)

@fasterthanlime

This comment has been minimized.

Collaborator

fasterthanlime commented Aug 18, 2014

Ahhhhh got no time to review - can you merge & I'll review later? master is unstable now so it's okay(TM).

(Or maybe @zhaihj wants to review?)

@alexnask

This comment has been minimized.

Collaborator

alexnask commented Aug 18, 2014

Well the tests and Travis-CI build pass and I trust the code has no side-effects, I guess I'm just treading carefully until I get accustomed to rock once more :P

Anyway, I'm merging, those are pretty trivial changes

@alexnask alexnask closed this in c77aff1 Aug 18, 2014

@davidhesselbom

This comment has been minimized.

Contributor

davidhesselbom commented Aug 19, 2014

I had a file like this:

import ./internal
import math

extend Float {
    absolute: static func(value: This) -> This {
        value >= 0 ? value : -1 * value
    }
}

that used to work fine, but after this issue was closed, my file no longer compiles: "Invalid use of modifier static outside of a type declaration". What is the purpose of disallowing extensions from having static methods?

@fasterthanlime

This comment has been minimized.

Collaborator

fasterthanlime commented Aug 19, 2014

Simple oversight from @Shamanas's part I suppose?

Btw, we should have tests for this (with //! shouldfail - so that sam
checks that rock errs out)

On Tue, Aug 19, 2014 at 10:24 AM, davidhesselbom notifications@github.com
wrote:

I had a file like this:

import ./internal
import math

extend Float {
absolute: static func(value: This) -> This {
value >= 0 ? value : -1 * value
}
}

that used to work fine, but after this issue was close, my file no longer
compiles: "Invalid use of modifier static outside of a type declaration".
What is the purpose of disallowing extensions to have static methods?


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

@alexnask

This comment has been minimized.

Collaborator

alexnask commented Aug 19, 2014

It was not my intention to do that, I though that extentions where actually TypeDefs, it seems not, fixing + adding testcase.

And I did add tests. :P

@fasterthanlime

This comment has been minimized.

Collaborator

fasterthanlime commented Aug 19, 2014

But... extensions should allow static - just not 'abstract', for example

On Tue, Aug 19, 2014 at 10:32 AM, Alexandros Naskos <
notifications@github.com> wrote:

It was not my intention to do that, I though that extentions where
actually TypeDefs, it seems not, fixing + adding testcase.

And I did add tests. :P


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

@fasterthanlime

This comment has been minimized.

Collaborator

fasterthanlime commented Aug 19, 2014

And I did add tests. :P

Well, I didn't have time to check it yet, but I wanted to mention the
undocumented sam feature

On Tue, Aug 19, 2014 at 10:35 AM, Amos Wenger fasterthanlime@gmail.com
wrote:

But... extensions should allow static - just not 'abstract', for example

On Tue, Aug 19, 2014 at 10:32 AM, Alexandros Naskos <
notifications@github.com> wrote:

It was not my intention to do that, I though that extentions where
actually TypeDefs, it seems not, fixing + adding testcase.

And I did add tests. :P


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

@alexnask

This comment has been minimized.

Collaborator

alexnask commented Aug 19, 2014

Ok, I have to make it a little more specific then.
I guess extentions should only disallow abstract?

@davidhesselbom

This comment has been minimized.

Contributor

davidhesselbom commented Aug 19, 2014

Maybe this is overly complicating things, but what if you want to create an extension for a type, and then inherit that type? Then extensions could have use for abstract. Otherwise, I guess it's not necessary.

@alexnask

This comment has been minimized.

Collaborator

alexnask commented Aug 19, 2014

Don't quote me on that but I don't think it would work.
I believe extend-s (Addons) cannot modify the metaclass of the type they extend, so abstract methods won't work for them (it won't segfault or anything, the abstract method you are adding will not be inherited though)

@davidhesselbom

This comment has been minimized.

Contributor

davidhesselbom commented Aug 19, 2014

I guess that settles it then :)

@fasterthanlime

This comment has been minimized.

Collaborator

fasterthanlime commented Aug 19, 2014

The greek boy is correct. No class/inheritance for addons, they're just
sugar.

On Tue, Aug 19, 2014 at 11:06 AM, davidhesselbom notifications@github.com
wrote:

I guess that settles it then :)


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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment