Open masak opened 9 years ago
And C#'s upcoming records don't appear to be the same, syntactically, as Simula and what I'd like for 007's "exotic" syntax — the former is syntactic sugar for a very predictable value class (well, a "record"), while the latter contains the constructor arguments up in the class declaration header while still having an explicit body (where the constructor parameters are in scope).
Proposed syntax:
(Here's the Perl 6 class for comparison:)
A couple of things of note:
__init__
method. You're not expected to need one.self
, there's nothis
. The variables declared withmy
in the class block happen to be lexically available in the methods, but that's all.There's no class inheritance.setProp
(orbutWith
or whatever we end up calling it).my
orsub
inside the class block is conservatively disallowed.BEGIN
block instead. On similar grounds,BEGIN
blocks are out.constant
declarations might be OK, though. They'd be a kind of once-only variables, valid throughout the class. If we wanted to be fancy, we could even allowMyClass.someConstant
to resolve. But I doubt we'd want to be that fancy.Q::Statement::My
toQ.Statement.My
.) Eventually decided against it because it feels like it's confusing together two very different things: the closed declaration of a class and its attributes/methods, and the open-ended declaration of namespaces.The syntax for creating an object mirrors object literals quite a lot.
(In this case, we could've skipped passing
assignment
, as it's already optional.We could have used the
new
keyword in the construction syntax, but I don't feel that it adds anything.As a nice retrofit, writing
Object { ... }
also works, and means the same as an ordinary object literal. Unlike user-defined classes, theObject
type doesn't check for required or superfluous properties.Tuple classes
After we get types, I'd very much like for us to get a "tuple class" syntax, where you don't name your attributes, but only specify their types as a tuple:
And the corresponding constructor syntax would look like a function call:
Internally, the attributes of a tuple class could have 0-based indices instead of names, and so you could still index them with
getProp
et al. This type of class would really shine if we had ADTs and case matching, the issue which see.Meta-object protocol
If you ask
type(Q::Statement::My)
, you get back the answerType
. (Much like Python.) Here's a rough attempt to getType
to "close the loop", meta-object-wise. Using the conjectural/future type syntax.