Синтаксис ярлыка при прямой реализации интерфейса

Можно ли реализовать цейлонскую проверку типов таким образом, чтобы класс, который напрямую удовлетворяет интерфейсу (типы в сигнатурах членов такие же, как и в удовлетворяемом интерфейсе), мог опускать типы в своих собственных подписях членов?

Это помогло бы уменьшить визуальный беспорядок на месте реализации за счет перемещения всей метаинформации (типы, аннотации) в интерфейс. И это помогает сосредоточиться на деталях реализации.

Это было бы близко к файлу подписи в ocaml.

И это могло бы помочь сказать больше, более ясно.

Отредактировано после того, как Лукас Веркмайстер дал ответ:

Я хотел бы иметь сокращенный синтаксис, который работает не только для атрибутов, но и для методов.

Посмотрите на «имя (x)» в классе Person:

interface Named {
    shared formal String name(String n);
}
class Person(shared String  firstName, shared String lastName) satisfies Named {

    name(x) => firstName + x +" " + lastName;

}

Named named = Person("Lucas", "Werkmeister");
print(named.name);

ceylon
person Michael    schedule 25.02.2016    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Это недопустимо, потому что это было бы слишком синтаксически двусмысленно. То есть синтаксический анализатор не может отличить name(x, y, z) от выражения вызова, пока, наконец, не встретится с =>. Это может привести к довольно нежелательному поведению, например, в среде IDE, когда вы начнете вводить уточнение ярлыка, синтаксический анализатор воспримет его как выражение вызова и отобразит ошибки на x, y и z.

В общем, мы очень тщательно следим за тем, чтобы у нас не было никаких синтаксических конструкций, требующих слишком много времени для понимания.

person Gavin King    schedule 26.02.2016
comment
Критерием принятия решения не должно быть то, что делает синтаксический анализатор. Важно уважать потребности пользователя языка. - person Michael; 07.03.2016
comment
Я думаю, что это очень наивный способ разработки синтаксиса языка. Если инструменты (то есть компилятор, IDE) не могут легко устранить неоднозначность синтаксической конструкции, то взаимодействие с пользователем будет ужасным: запутанные сообщения об ошибках, неисправное автозаполнение и т. д. и т. д. Уважение потребностей пользователя включает в себя внимание к каков пользовательский опыт, когда они написали что-то немного неправильное или немного неполное. - person Gavin King; 08.03.2016

arrow_upward
1
arrow_downward

Да, с синтаксисом уточнения быстрого доступа: вы можете просто написать thing => ...; вместо shared actual Type thing => ...;. Например

interface Named {
    shared formal String name;
}
class Person(firstName, lastName) satisfies Named {
    shared String firstName;
    shared String lastName;

    name => firstName + " " + lastName;
    // shortcut for
    // shared actual String name => …;
}

Named named = Person("Lucas", "Werkmeister");
print(named.name);

Попробуйте онлайн

person Lucas Werkmeister    schedule 25.02.2016

arrow_upward
1
arrow_downward

Уточнение ярлыков работает и с методами, вам просто нужно указать типы параметров:

interface Named {
    shared formal String name(String n);
}

class Person(shared String  firstName, shared String lastName) satisfies Named {
    name(String x) => firstName + x +" " + lastName;
}
person gdejohn    schedule 25.02.2016
comment
Ну да. Но типы параметров на самом деле не нужны для вывода типов. В scala: абстрактный класс A { var a : Int }; класс B расширяет A { var a = 2}; Напротив, вывод типа Цейлона несколько слаб. - person Michael; 25.02.2016
comment
Я ожидал, что это сработает на Цейлоне: String( String ) name = (x) => x: + x; В scala правильно говорить: val a : Int => Int = (s) => 3; - person Michael; 25.02.2016
comment
Это обсуждение, вероятно, лучше подходит для GitHub. - person gdejohn; 26.02.2016