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

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

Projects

None yet

3 participants

@shamanas
Collaborator

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
@shamanas shamanas self-assigned this Aug 18, 2014
@fasterthanlime
Collaborator

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.

@shamanas
Collaborator

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

@shamanas shamanas 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
@shamanas shamanas added Front-end and removed Middle-end labels Aug 18, 2014
@shamanas
Collaborator

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
Collaborator

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?)

@shamanas
Collaborator

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

@shamanas shamanas closed this in c77aff1 Aug 18, 2014
@davidhesselbom
Contributor

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
Collaborator

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).

@shamanas
Collaborator

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
Collaborator

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
Collaborator

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)
.

@shamanas
Collaborator

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

@davidhesselbom
Contributor

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.

@shamanas
Collaborator

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
Contributor

I guess that settles it then :)

@fasterthanlime
Collaborator

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).

@fasterthanlime fasterthanlime modified the milestone: 0.9.10 Jul 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment