Empty class definitions
Kurtis Rainbolt-Greene
Bob Nystrom
<kurtisrain...@gmail.com> wrote:
> While I ultimately enjoy the class definition syntax in Magpie it was weird,
> going through the source, and seeing this:
>
> defclass SomeClass
> end
Agreed, it is a little strange. I think you generally only see this
with classes in the core lib that exist to wrap some interpreter
internal state. I wouldn't expect most user-defined classes to have no
fields at all, so my hope is the above code wouldn't occur much in
practice.
>
> Without breaking the Magpie vision, could there be a way around this? I come
> from Ruby, so namespacing comes in the form of defining modules/classes
> inside modules/classes (nested style):
>
> defclass SomeClass
> def some_method
> end
>
> defclass AnotherClass
> end
> end
I've toyed with some syntactic sugar to let you define methods inside
class bodies, but right now at least, I'm trying to avoid it:
1. It really is syntactic sugar since you can also define methods
outside of classes, and being able to do so (and to define methods
whose left-hand side isn't a class) is a big part of what Magpie is.
2. I worry that having a shorthand that groups methods and classes
together might encourage a confusing mental model. As strange as it
seems for an "OOP" language, Magpie doesn't actually group state and
the methods that operate on that state together. It isn't OOP in that
sense.
It's much more like C (structs + functions) or CLOS (classes + generic
methods). The syntax for *calling* methods is designed to still read
like a familiar OOP language because I think receiver.method(arg)
matches very well with the subject-verb-object word order we use. I
think it reads right.
But as far as semantics and stuff goes, methods really aren't tied to
classes. When you have something like:
foo bar(bang)
You're calling "bar" and passing it "foo" and "bang". Compared to
"bang", there's absolutely nothing special about "foo": they're both
just plain old arguments. One just happens to be before the method
name and one is after.
Given that, I worry that syntactic sugar for defining methods on a
certain left-hand argument without having something similar for
right-hand arguments would be strangely unsymmetric. But maybe that's
just me.
I like that the current syntax for methods tends to keep your code
pretty flat: everything is defined at the top level of the file
without a lot of namespace or class indentation. The downside is that
there's a good bit of repetition when you do define a bunch of methods
with the same argument patterns.
- bob