VD>Ага. Но без хорошей реализации это бы все было фигней.

но теоретического предела все равно же и близко не удалось достичь.
значит где-то еще есть неоптимальности в реализации

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

U>>Любая функция (конструктор в том числе) это действие, действие это глагол, соответственно функция не имеющая в названии глагола это не понятно что.

Соответственно я не понимаю, почему отсутствие действия означает создание. Понять это невозможно, это можно только запомнить, т.е. это неочевидно, а, значит, плохо.

DG>т.е. ты в своем коде не используешь свойств?
DG>это же тоже всё действия.

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

DG>методы toString/fromString, наверное, тоже не используешь?
DG>переписал их на расовополноценные — createString и createFromString?

Предлоги в, из подразумевают преобразование, даже в естественных языках. Соответственно аналогия не к месту, фраза "некоторый объект" никакого действия не подразумевает.

U>>>>Я правильно понял, что если тебе нужен метод создающий объект, то ты сейчас пишешь не CreateSomeObject(), а SomeObject()?

DG>потому что в шарпе так все равно нельзя
DG>а в q# — да, и так экспериментирую

В смысле? В шарпе нельзя написать DatabaseHlp.TableForImei() вместо DatabaseHlp.CreateTableForImei()?

DG>>потому что в шарпе так все равно нельзя
DG>>а в q# — да, и так экспериментирую

U>В смысле? В шарпе нельзя написать DatabaseHlp.TableForImei() вместо DatabaseHlp.CreateTableForImei()?

да, можно.
только и первое, и второе — пример ужасного кода

ты для начала ответь — что именно необходимо выносить в название функции?

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

DG>ты для начала ответь — что именно необходимо выносить в название функции?

Действие, которое функция выполняет.

DG>>ты для начала ответь — что именно необходимо выносить в название функции?

U>Действие, которое функция выполняет.

полный ответ, пожалуйста.
вот есть произвольная функция — что именно должно быть отражено в названии функции.

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

Вот, правильную тему поднял. Я пытался как-то "на бумаге" рарабатывать ЯП, который был мне удобен. Брал некие популярные задачи. Под одни из них синтаксис заточишь — в других местах сценариях неудобно. А вводить в синтаксис case или first-letter conventions, как в Хаскеле или Фортран — как-то несовременно.

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

R3>Да, я про это и говорю. Но нужен не только вывод типов у компилятора, но нужна и память программисту — он должен помнить, что возвращает Class1(): инициализированный класс, или какой-то результат функции.

А в чем принципиальная разница? Возвращается некое значение.
Тут более полезно разделить вызов ф-ии и процедуры (для императивных языков), например как в VB, тогда читабельность не страдает.

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

V>Вот, правильную тему поднял. Я пытался как-то "на бумаге" рарабатывать ЯП, который был мне удобен. Брал некие популярные задачи. Под одни из них синтаксис заточишь — в других местах сценариях неудобно. А вводить в синтаксис case или first-letter conventions, как в Хаскеле или Фортран — как-то несовременно.

и к чему в итоге пришел?

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

R3>>Да, я про это и говорю. Но нужен не только вывод типов у компилятора, но нужна и память программисту — он должен помнить, что возвращает Class1(): инициализированный класс, или какой-то результат функции.
V>А в чем принципиальная разница? Возвращается некое значение.

В случае с new мне достаточно в памяти держать только описание классов.
В случае без new — ещё и результаты выполнения функций.

Ну и ещё как-то так:

public class MyClass
{
  public MyClass() { }
}

public Main
{
  private object MyClass() { }
  private void DoWork()
  {
    object o = MyClass(); // ?
  }
}

V>Тут более полезно разделить вызов ф-ии и процедуры (для императивных языков), например как в VB, тогда читабельность не страдает.

Функции можно использовать также, как и процедуры (но не наоборот), т.е. процедуры — подмножество функций. Зачем их делить?

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

U>>В смысле? В шарпе нельзя написать DatabaseHlp.TableForImei() вместо DatabaseHlp.CreateTableForImei()?

DG>только и первое, и второе — пример ужасного кода

И что во втором варианте ужасного? Статических функций очень много, соответственно их в любом случае надо разбивать на группы. Чем способ разбиения на группы с помощью предиката в виде имени статического класса хуже любого другого?

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

U>>Действие, которое функция выполняет.

DG>полный ответ, пожалуйста.
DG>вот есть произвольная функция — что именно должно быть отражено в названии функции.

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

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

R3>Функции можно использовать также, как и процедуры (но не наоборот), т.е. процедуры — подмножество функций. Зачем их делить?

Затем, что с результатом тоже что-то делать надо и это должно быть частью типобезопасности, проверяемой компилятором.

Насчет "так же использовать" — это и есть популярная детская ошибка с игнорированием кодов возвратов, например.

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

V>>Вот, правильную тему поднял. Я пытался как-то "на бумаге" рарабатывать ЯП, который был мне удобен. Брал некие популярные задачи. Под одни из них синтаксис заточишь — в других местах сценариях неудобно. А вводить в синтаксис case или first-letter conventions, как в Хаскеле или Фортран — как-то несовременно.

NB>и к чему в итоге пришел?

Что "по шустряку" последовательный синтаксис разработать не выйдет.

Реально, раз в несколько лет я к этой теме возвращаюсь, ибо написать компилятор не проблема (даже с учетом трудозатрат на отладку его грамматики), проблема — построить непротиворечивые спецификации Языка.

Мне понравилась работа Воронкова Василия именно тем, что он попытался разработать стройный синтаксис. Особенно в первых версиях. Потом у него понесся перекос в сторону Хаскеля, угу, я бы оставил на ключевых словах, типа function, для соблюдения духа синтаксиса. Справедливости ради, у него всё-равно очень неплохо вышло. И хотя в наличии лишь интерпретатор, под этот язык может быть построен типобезопасный компиллер, бо присутствует предварительное объявление переменных (там пара моментов всего нужна для доработки, не суть). Да и наличие своей VM говорит о заточке под компиляцию. В остальном, черпать вдохновение в JavaScript было абсолютно правильно, ибо много интересных идей, просящихся в компиллируемую реализацию.

U>Это и был полный ответ, т.к. этой формулировки вполне достаточно для придумывания названий функций в реальных задачах.

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

зы
один из критериев хорошего названия — не тащить в названия "физику".
на языке обычно описывает модель определенного мира, но слова new, create, get, set — это слова языка, а не слова выстраиваемой модели — поэтому они лишние.

например, во фразе:

table().paint-to(color('green'))

слово create лишнее, т.к. на самом деле никакой новый стол не создается, и новый цвет тем более(они уже все созданы реальным миром)

createTable().paint-to(createColor('green'))

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

DG>например, во фразе:
DG>

DG>table().paint-to(color('green'))
DG>

DG>слово create лишнее, т.к. на самом деле никакой новый стол не создается, и новый цвет тем более(они уже все созданы реальным миром)
DG>

DG>createTable().paint-to(createColor('green'))
DG>

По-моему там и color — лишнее
Точней яб записал как:

table().color(green)

Правда, наверное, не всеми color воспринимается как глагол, поэтому, возможно стоит оставить paint-to (хотя корректность его меня смущает)

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

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

В каком это месте формулировки:

Название функции должно включать в себя действие, которое функция выполняет.

недостаточно для определения хорошее это название или плохое? Я что-то не улавливаю твоей логики.

DG>зы
DG>один из критериев хорошего названия — не тащить в названия "физику".
DG>на языке обычно описывает модель определенного мира, но слова new, create, get, set — это слова языка, а не слова выстраиваемой модели — поэтому они лишние.

Слова create (и new как синоним/аналог create) это именно слова выстраиваемой модели, а вовсе не языка. И соответственно если их опускать, то вместо описания модели какая-то фигня получается.

DG>например, во фразе:
DG>

DG>table().paint-to(color('green'))
DG>

DG>слово create лишнее, т.к. на самом деле никакой новый стол не создается, и новый цвет тем более(они уже все созданы реальным миром)
DG>

DG>createTable().paint-to(createColor('green'))
DG>

CreateTable создает стол в модели мира, до вызова этого метода никакого стола в рамках модели нет. Соответственно для нас важно видеть, что после этого вызова в модели появился новый объект, поэтому слово Create необходимо, т.к. резко упрощает чтение кода.

С цветом пример вообще не в тему. Цвет стола это либо свойство, либо вообще readonly поле, в каком месте цвет является действием и соответственно зачем ты пытаешься его задать функцией не понятно.

U>недостаточно для определения хорошее это название или плохое? Я что-то не улавливаю твоей логики.

недостаточное, конечно.

U>CreateTable создает стол в модели мира, до вызова этого метода никакого стола в рамках модели нет. Соответственно для нас важно видеть, что после этого вызова в модели появился новый объект, поэтому слово Create необходимо, т.к. резко упрощает чтение кода.

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

U> С цветом пример вообще не в тему. Цвет стола это либо свойство, либо вообще readonly поле, в каком месте цвет является действием и соответственно зачем ты пытаешься его задать функцией не понятно.

так значит ты еще не чувствуешь — когда что-то делается действием? а когда свойством?
действие можно заменять на свойство — только если не важны нюансы процесса изменения.
банальный пример машина и ее движение.
если в нашей модели не важно — как машина едет, то достаточно будет свойства координаты машины и их изменение.
если же важно, например, как именно машина едет, как у нее там мотор фурчит и бензин тратится, то придется вводить метод move(go/drive/ride и т.д.)

то же самое и со столом, раз введен метод paint-to значит важны нюансы перекраски — может это длительная по времени операция, может там его сначала надо зашкурить, покрыть грунтовкой и только потом красить, и т.д. — и всё это важно.

но речь-то шла не об этом, а о том, насколько уместно говорить о создании цвета, или о создании точки, или о создании человека

U> Соответственно для нас важно видеть, что после этого вызова в модели появился новый объект

почему это важно? критерий. что произойдет страшного — если мы забудет о том, что вот данная функция создает объект?
приучайся свои интуитивные ощущения — логически обосновывать, т.к. интуация во многих ситуациях выдает ответ нечетко и легко ошибится в его трактовке.

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


R3>Да, я про это и говорю. Но нужен не только вывод типов у компилятора, но нужна и память программисту — он должен помнить, что возвращает Class1(): инициализированный класс, или какой-то результат функции.
R3>Не знаю, на сколько это действительно важно.

От языка зависит, например в питоне во первых все объект и поэтому все что возвращают функции все-равно объекты, во вторых сами классы тоже первоклассные объекты, и функции могут возвращать не только объекты но и классы:

def create(cls):
    return cls()
    
    
def tst(cls):
    x = create(cls)
    print x, type(x)
    

tst(int)
tst(str)
tst(float)

0 <type 'int'>
 <type 'str'>
0.0 <type 'float'>

и из этой же первоклассности следует что классы не больше чем экземпляры метаклассов и вызов конструктора класса не более чем вызов оператора __call__ метакласса. И в такой модели оператор new совершенно излишен.

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

U>Вообще-то функции, которые создают объект, но не начинаются со слова Create

Функции виде CreateXxx это лишь одно из принятых соглашений (FactoryMethod). Точно так же можно принять соглашение, что функция с именем Xxx() создает объект типа Xxx. Никаких препятствий для этого нет.

Более того, конструкторы должны вести ровно так же, как любые другие функции языка, оператор new этому мешает.