I don't understand this. You say there's an issue, you give an example, then you say that "situations like this are usually handled correctly." and then "it's fixed by..." Is there a problem? If so, what is it? Can you provide an example where it is not handled correctly?

var/name = "global"

Object
    var/name = "object"
    proc/print_name(name)
        world << name

mob/Login()
    var/Object/o = new /Object()
    o.print_name("argument")

A/proc/print()
    world << "hello, world!"

B
    var
        A/text = new /A()
    proc
        print()
            // error:text :bad format string
            text.print()

mob
    Login()
        var/B/b = new /B()
        b.print()

And if the default was to include all namespaces this wouldn't break old code.

Or "no namespace." You wouldn't want to require everything to have a namespace. At least, I wouldn't think you would want to.

proc
    something(txt)
        txt = BYOND.String.copytext(...)

using BYOND.String

proc
    something(txt)
        txt = copytext(...)

Probably better would be static functions, then you could have something that worked basically just like a namespace for what you want but was more powerful. That would be awkward with the way Byond does object type references though. Might look something like /string.copytext() or /string:copytext().

Not seeing how a few keywords being reserved means we need namespaces. Also not seeing how namespaces would actually make anything simpler... you justify it by saying that you would be able to search the reference by them, but that would be considerably easier to do by simply providing a new way of browsing through the reference.

Static methods aren't more powerful, they're just different.

I was surprised to find that the substring function is called copytext. I was also surprised to find that there's no string split function. Even a small amount of programming experience prior to using DM will give you expectations about what DM should have and what it might be called.

I'm mostly with this line of thought. I don't think namespaces make anything simpler until you already know what you're doing, which is not the majority of BYOND users.

Namespaces are really just inheritance and categorical grouping for members/methods, but I don't really think it's that necessary for BYOND.

<small>Personally I'd rather see better naming conventions for built-in methods and variables. Having procs with unreliable case and convention, like "step_away()" "SwapColor()" "Swap()" "text()" "text2ascii()" was confusing at first, and doesn't teach very good ettiquette.</small>

> Something
>   static
>       method()
>           // do something
> 
> mob
>   Login()
>       world << Something.method()
>

But with namespaces it's possible to do this:

> using Something
> 
> proc
>   method()
>       set namespace = Something
>       // do something
> 
> mob
>   Login()
>       world << method()
>

MyObject
    var/static/stuff = "whatever"

    proc
        static/myStaticFunction()
            ...

proc/stuff()
    set namespace = MyObject
    world << stuff
    myStaticFunction()

proc/stuff()
    with MyObject
    world << stuff
    myStaticFunction()

proc/stuff()
    with MyObject
        world << stuff
        myStaticFunction()

void myFunction()
{
    std::string myString;
    MyObject::myStaticFunction();
}

var/global/myVar

obj
    var/myVar

    proc/stuff(myVar)

import static MyClass.myStaticMember;

public class Tester
{
    public static void main(String[] args)
    {
        System.out.println(myStaticMember);
    }
}

import static MyClass.*;

import static javax.swing.WindowConstants.*;
import javax.swing.JFrame;

public class Test
{
    public static void main(String[] args)
    {
        JFrame frmMain = new JFrame("My Tester Frame"),
            frmSub = new JFrame("My Subframe");
        frmMain.setDefaultCloseOperation(EXIT_ON_CLOSE); // instead of WindowConstants.EXIT_ON_CLOSE
        frmSub.setDefaultCloseOperation(DISPOSE_ON_CLOSE); // instead of WindowConstants.DISPOSE_ON_CLOSE
        frmMain.setVisible(true);
        frmSub.setVisible(true);
    }
}

Personally I'd rather see better naming conventions for built-in methods and variables. Having procs with unreliable case and convention, like "step_away()" "SwapColor()" "Swap()" "text()" "text2ascii()" was confusing at first, and doesn't teach very good ettiquette.

The code may be ambiguous to you, but it should never be ambiguous to the compiler. If it was, that would mean that it's possible to run the compiler twice with the same settings and same input and get two functionally different programs. This would be quite a problem.

Code may be ambiguous to a person if the person doesn't understand how the compiler works. For example:

I hadn't thought about static methods much, what would the benefits be over using existing techniques as a workaround?

Are there any particular uses for static methods you have in mind?