Как думаете, какой способ предпочтительнее с точки зрения дизайна языка программирования?
Из того, что попадалось:
1. имя класса
class MyClass
{
MyClass();
~MyClass();
};

2. ключевое слово this или другое, используемое также для каких-либо других целей
class MyClass
{
this();
~this();
};


3. отдельные ключевые слова = функции с предопределенными именами
class MyClass
{
ctor();
dtor();
};

Учитывается понятность и внешний вид кода, отсутствие неоднозначностей, удобство рефакторинга и работы IDE и любые другие факторы, которые могут иметь место.

Здравствуйте, x-code, Вы писали:

XC>3. отдельные ключевые слова = функции с предопределенными именами
XC>class MyClass
XC>{
XC> ctor();
XC> dtor();
XC>};

Мне последний вариант больше нравится.

Здравствуйте, x-code, Вы писали:

По-моему, первый. Констурктор же вызывается не изнутри класса, а откуда-то из другого места, поэтому this там будет неоднозначно воприниматься. А ctor — одинковое название для любого класса — то же визуально плохо, так как набор этих самых ctor запутает. А в первом собсобе сразу видно кто для чего и зачем

Здравствуйте, Anpek, Вы писали:

A>По-моему, первый. Констурктор же вызывается не изнутри класса, а откуда-то из другого места, поэтому this там будет неоднозначно воприниматься. А ctor — одинковое название для любого класса — то же визуально плохо, так как набор этих самых ctor запутает. А в первом собсобе сразу видно кто для чего и зачем

Топикстартер предоставил синтаксис определения, а не вызова. Вызов, я так полагаю, по прежнему будет new MyClass(params).

Здравствуйте, Qbit86, Вы писали:

Q>Топикстартер предоставил синтаксис определения, а не вызова. Вызов, я так полагаю, по прежнему будет new MyClass(params).

Да, именно так.

Здравствуйте, x-code, Вы писали:

Голосую за №3.

XC>Как думаете, какой способ предпочтительнее с точки зрения дизайна языка программирования?

XC>Учитывается понятность и внешний вид кода, отсутствие неоднозначностей, удобство рефакторинга и работы IDE и любые другие факторы, которые могут иметь место.

Голосую за №3: предопределённые имена. Обязательно НЕ ключевые, то есть чтоб их можно было использовать в названиях переменных. Хотя последняя хотелка, конечно, сильно зависит от остальных дизайн решений.

Только слова надо поаккуратнее выбрать. В частности, чем единственное чем плохи constructor/destructor — они не глаголы, хотя имена методов по логике должны быть глаголами. create/destroy например.

Здравствуйте, x-code, Вы писали:

[...]

2й или 3й вариант ничем не отличаются, "~this" это такая же лексема что и "dtor". Голосую за любой из них.

1й вариант плох тем что надо повторять компилятору то что он уже знает.
При переименовании класса надо менять имя в бОльшем количестве мест.
Также если код генерируется каким-то метакодом, это делает невозможным многие вещи, например

DEFINE_CLASS_WITH_UNIQUE_NAME
{
    ...
    тут нельзя написать конструктор потому что мы не знаем имя класса
};

или

DEFINE_CLASS(Foo)
{
    ...
    DEFINE_CTOR(Foo) // тут опять надо зачем-то писать имя класса 
    {
        ...
    }
};

Здравствуйте, Temoto, Вы писали:

T>...чем единственное чем плохи constructor/destructor — они не глаголы...

Это имеет значение только для вызова. А при вызове существительные «ctor» и «dtor» не используется.

XC>Учитывается понятность и внешний вид кода, отсутствие неоднозначностей, удобство рефакторинга и работы IDE и любые другие факторы, которые могут иметь место.

дублирование информации
устранение дублирование информации — уменьшает накладные расходы при изменении кода (поменять название класса, сделать дубль класса с чуть другим функционалом и т.д.)
имена this/~this, ctor/dtor по сравнению с MyClass уменьшают дублирование информации

конфликт имен (полнота)
полнота(возможность всех вариантов) важна при автоматической генерации кода, интеграции, версионности и т.д., т.е. в тех случаях, когда затруднена возможность произвольного задания имен.
если для объявления конструктора/деструктора используется тот же самый синтаксис, что и для объявления методов, то возникает конфликт имен: есть сложности объявления функций с теми именами, которые зарезервированы для конструктора/деструктора
вариант MyClass делает невозможным объявление метода с именем MyClass.
вариант this запрещает методы this, но для языков где this зарезервированное слово(а не просто контекстно-зависимое), такие методы и так не возможны
вариант ctor/dtor запрещает методы ctor/dtor
конфликт может решаться устранением неоднозначности другими способами:
например(общий для всех трех вариантов, для статически-типизированных языков): метод — отличается добавление объявление результата. MyClass() — конструктор, а void MyClass() — метод.
например(общий для всех трех вариантов): метод — отличается добавлением @ перед названием. MyClass() — конструктор, а @MyClass() — метод.
но при беглом просмотре и для новичков, неоднозначность все равно может возникать

чтение кода с любого места в произвольном направлении (обычно конфликтует с критерием дублирование информации)
полезно при беглом чтении кода, анализе, частичном автоматизированном разборе и т.д.
конструктор/деструктор могут быть достаточно отдалены от объявления самого класса, а для названий this/~this, ctor/dtor вообще нет никаких подсказок о каких конструкторах/деструкторах идет речь, что требует либо аккуратный скроллинг к объявлению класса (при беглом скроллинге можно перескочить на чужое объявление), либо подсказок от IDE. с методами проблема менее критична, т.к. название метода уже часто несет большую часть информации — что это за метод, и название класса необходимо только когда метод реально полиморфный.


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

поэтому мне больше нравится вариант: MyClass, но с возможностью, если сильно хочется, объявить метод с тем же именем

T>>...чем единственное чем плохи constructor/destructor — они не глаголы...

Q>Это имеет значение только для вызова. А при вызове существительные «ctor» и «dtor» не используется.

Смотря какая грамматика.

Если рассматривать

"constructor" "(" arguments... ")"

, где constructor — ключевое слово, наравне с class/switch/return, то да, вы правы. А если рассматривать

id "(" arguments... ")"

, где "constructor" это частный случай идентификатора и оно не является никаким ключевым словом или специальной грамматической конструкцией, то нет, имя должно подчиняться тем же правилам, что и у остальных методов.

Здравствуйте, DarkGray, Вы писали:

DG>чтение кода с любого места в произвольном направлении (обычно конфликтует с критерием дублирование информации)
1. ИДЕ должна показывать текущий контекст
2. та же проблема с методами — смотришь на метод, и не видишь чей он.

Здравствуйте, x-code, Вы писали:

XC>Учитывается понятность и внешний вид кода, отсутствие неоднозначностей, удобство рефакторинга и работы IDE и любые другие факторы, которые могут иметь место.

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

Здравствуйте, x-code, Вы писали:

XC>Здравствуйте, Qbit86, Вы писали:

Q>>Топикстартер предоставил синтаксис определения, а не вызова. Вызов, я так полагаю, по прежнему будет new MyClass(params).

XC>Да, именно так.

а смысл писать вдобавок методы типа ctor()/this() , если всё равно будет вызываться new MyClass() ???

Здравствуйте, Abyx, Вы писали:

A>Здравствуйте, x-code, Вы писали:

A>[...]

A>2й или 3й вариант ничем не отличаются, "~this" это такая же лексема что и "dtor". Голосую за любой из них.

A>1й вариант плох тем что надо повторять компилятору то что он уже знает.
A>При переименовании класса надо менять имя в бОльшем количестве мест.
A>Также если код генерируется каким-то метакодом, это делает невозможным многие вещи, например
A>

A>DEFINE_CLASS_WITH_UNIQUE_NAME
A>{
A>    ...
A>    тут нельзя написать конструктор потому что мы не знаем имя класса
A>};
A>

A>или
A>

A>DEFINE_CLASS(Foo)
A>{
A>    ...
A>    DEFINE_CTOR(Foo) // тут опять надо зачем-то писать имя класса 
A>    {
A>        ...
A>    }
A>};
A>

Это еще почему? Что за генерация такая, что имя класса известно, а конструктор нельзя объявить?
А как тогда планируется в вызывающем коде создавать оюъект методом ctor() ?

Здравствуйте, blackhearted, Вы писали:

Q>>>Топикстартер предоставил синтаксис определения, а не вызова. Вызов, я так полагаю, по прежнему будет new MyClass(params).

B>а смысл писать вдобавок методы типа ctor()/this() , если всё равно будет вызываться new MyClass() ???

Чтобы избежать избыточности (и всех её негативных последствий) в определении класса.

Здравствуйте, Abyx, Вы писали:

A>Здравствуйте, DarkGray, Вы писали:

DG>>чтение кода с любого места в произвольном направлении (обычно конфликтует с критерием дублирование информации)
A>1. ИДЕ должна показывать текущий контекст
A>2. та же проблема с методами — смотришь на метод, и не видишь чей он.

всегда только IDE?
Можно вообще уйти от фиксированных имён и аннотировать методы.
Что-то типа @Constructor. Тогда без IDE будет полный пипец. А такие ситуации довольно часты.

Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, blackhearted, Вы писали:

Q>>>>Топикстартер предоставил синтаксис определения, а не вызова. Вызов, я так полагаю, по прежнему будет new MyClass(params).

B>>а смысл писать вдобавок методы типа ctor()/this() , если всё равно будет вызываться new MyClass() ???

Q>Чтобы избежать избыточности (и всех её негативных последствий) в определении класса.

и какие негативные последствия у

public class A
{
   public A();
}

по сравнению с

public class A
{
   public ctor();
}

?

Здравствуйте, blackhearted, Вы писали:

B>Это еще почему? Что за генерация такая, что имя класса известно, а конструктор нельзя объявить?

Имя класса как раз может быть неизвестно.

B>А как тогда планируется в вызывающем коде создавать оюъект методом ctor()?

Это уже задача вызывающего кода. Он независим от библиотечного. Объявление класса и создание его экземпляра — это слабосвязанные вещи, они могут быть разделены в пространстве и времени. Создание происходит не вызовом ctor(params), а вызовом SomeGeneratedClass(params).

Здравствуйте, blackhearted, Вы писали:

[]

не оверквотьте.