![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
TMI: Do work, undo work, collect paycheck
May. 11th, 2012 10:20 pmFriday, I talked about @class on IRC with Patrick and Niko -- we concluded it's complicated and
unnecessary, so deferring it. Instead, I filed an RFC for static methods in classes. As in languages you may be more familiar with, static methods don't have an implicit self argument. They can take a self argument explicitly, of course. The only difference between a static method and a top-level function is that a static method can access class-private fields in its enclosing class. This would solve the problem of @class without needing special syntax.
I kind of feel foolish about spending 2-3 days on something when if I'd discussed it earlier, the answer would have been "YAGNI". Like I should have discussed it earlier. Then again, who knows what "should" means? Anyway, now there's an RFC open and with hope, we can improve the language, and hopefully avoid doing something ridiculously complicated (like @class was becoming). In general, behavior that's not reflected in types seems like a bad idea.
So I started afresh and wrote the code that actually checks whether self escapes. At first I wanted to make it part of the typechecker, but I realized because of how the visitors in the typechecker work, it was just easier to write a separate pass for the self-check. It was a very small amount of code -- just a visitor that skips over field references (since self.x is okay) and complains if it sees self anywhere else. I didn't end up finishing this till I was on the plane home on Sunday, though.
unnecessary, so deferring it. Instead, I filed an RFC for static methods in classes. As in languages you may be more familiar with, static methods don't have an implicit self argument. They can take a self argument explicitly, of course. The only difference between a static method and a top-level function is that a static method can access class-private fields in its enclosing class. This would solve the problem of @class without needing special syntax.
I kind of feel foolish about spending 2-3 days on something when if I'd discussed it earlier, the answer would have been "YAGNI". Like I should have discussed it earlier. Then again, who knows what "should" means? Anyway, now there's an RFC open and with hope, we can improve the language, and hopefully avoid doing something ridiculously complicated (like @class was becoming). In general, behavior that's not reflected in types seems like a bad idea.
So I started afresh and wrote the code that actually checks whether self escapes. At first I wanted to make it part of the typechecker, but I realized because of how the visitors in the typechecker work, it was just easier to write a separate pass for the self-check. It was a very small amount of code -- just a visitor that skips over field references (since self.x is okay) and complains if it sees self anywhere else. I didn't end up finishing this till I was on the plane home on Sunday, though.