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

feature request: implement error for overloading "final" methods #31222

Open
KristofferC opened this issue Mar 1, 2019 · 3 comments
Open

feature request: implement error for overloading "final" methods #31222

KristofferC opened this issue Mar 1, 2019 · 3 comments
Labels
design Design of APIs or of the language itself feature Indicates new feature / enhancement requests

Comments

@KristofferC
Copy link
Member

KristofferC commented Mar 1, 2019

From a (trolly) discourse post (https://discourse.julialang.org/t/module-with-one-function-of-same-name-as-the-module/21305/3):

module a
    _a() = println("Hello there!")
    function Base.getproperty(m::Module, x::Symbol)
        if m === a && x === :a
            return getfield(m, :_a)
        else
            return getfield(m, x)
        end
    end
end

Executing some stuff in the REPL

julia> a.a
Main.a

julia> b = a.a
_a (generic function with 1 method)

It seems odd to me that a.a returns Main.a instead of _a. Perhaps this is the interpreter that is running and take a fast path for getproperty and type piracy like this is not supported.

@KristofferC KristofferC changed the title Assignment doesnt always return RHS Interpreter takes an invalid(?) fast path for getproperty? Mar 1, 2019
@vtjnash vtjnash changed the title Interpreter takes an invalid(?) fast path for getproperty? feature request: implement error for overloading "final" methods Mar 1, 2019
@ararslan
Copy link
Member

ararslan commented Mar 1, 2019

@vtjnash, can you explain what the new issue title means?

@KristofferC
Copy link
Member Author

Probably that this type of type piracy should just error. Ie this method should be considered closed.

@JeffBezanson
Copy link
Member

👍 Yes, there are two nice features we could add here: (1) Sealed functions, where you can't add any new methods, and (2) sealed methods, where you can't replace it or add any methods more specific than it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Design of APIs or of the language itself feature Indicates new feature / enhancement requests
Projects
None yet
Development

No branches or pull requests

4 participants