JVM-based языки. Кто умеет такой синтаксис?

Хреново тебе.
Обязательно вытри жопу, а то ведь некрасиво; но, не раньше, чем когда хоть один недоязык под JVM(скала, груби, ...) позволит менять синтаксис ридера на лету.

Ты, видимо не выспался раз хочешь такие странные вещи.

Машу волшебной палочкой. Работает практически с любым синтаксисом, любого языка, любой реализации. Без неявностей и простыней лиспокода.

hash = ['item1', 'item2->subst', 1234]

'->', естественно, можно заменить на любой любимый символ разделения.

>Прошу прощения, я усрался!

Что интересно, оно совсем не решает то, что я спросил :)

>когда хоть один недоязык под JVM(скала, груби, ...) позволит менять синтаксис ридера на лету.

JBForth, поскольку он Forth, позволяет менять синтаксис ридера на лету :) Но это - другая история.

OMFG. Даже как-то возразить нечем :D Самое смешное, сам использую подобный синтаксис для возможности замены явно прописанной БД или для URL-привязок...

Почему оскорбления и ты - неотделимы. Жди бана и порезаного скора )

Даже близко не то :)

значит ты НЕ ПОСМОТРЕЛ.

ну что, для совсем Ъ вот 2 возможных варианта:

public class Enum3Test
{
  enum Mytable
  {
    FIELD1,
    FIELD2 {{ field="OTHER"; }},
    FIELD3;

    public String field=null;
  };

  enum Mytable2
  {
    FIELD1,
    FIELD2 { @Override public String toString() { return "ANOTHER"; } },
    FIELD3;
  };

  public static void main(String[] args)
  {
    for( Mytable t: Mytable.values() )
        System.out.println(t.field!=null?t.field:t.name());
    for( Mytable2 t: Mytable2.values() )
        System.out.println(t.toString());
  }
};

при наличии БОЛЬШЕГО числа необходимых атрибутов оверхед будет еще меньше

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

Я выше описывал. Например, для описания привязок полей в БД к методам/свойствам объекта в ORM.

Симптом напоминает РНР головного мозга. Так что ты вовремя начал интересоваться другими языками :-)

это делается так:

@DBTable("my_table") class Mytable {
  String field1;
  @DBField("other") String field2;
  String field3;
};

> hash = ['item1', 'item2->subst', 1234]

весьма практичное (хотя и грязное) решение для данного случая

оно накроется, если до и после "->" должны стоять не строки

> То есть я, конечно, понимаю, что Java-программерам семь копипаст - не дублирование,

гы-гы-гы. да, так оно и есть :-)

>ну что, для совсем Ъ вот 2 возможных варианта:

Нет, это ужасно :D

Так что ты вовремя начал интересоваться другими языками :-)

Да я ими и не прекращал интересоваться :)

это делается так:

Разумно (и в PHP тоже есть подобные реализации, но там это обеспечивает сильную потерю производительности).

Это в каком ORM сейчас так? Или в гипотетическом?

Я года три не щупал hibernate, там сделали нормальные JOIN'ы, постобработку загруженных данных, итераторы по массивам объектов? Можно ли определять автоматические геттеры-сеттеры?

...

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

>оно накроется, если до и после "->" должны стоять не строки

Ну, почему же? Будет же запрещён только сам символ - разделитель.

надо запомнить, хорошая подколка :-)

>@DBField(«other») String field2;

Чего-то я к Яве привыкать начинаю... В смысле, что не возник на тему избыточной длины :D Всё же, это не ('field2' => 'other') ...

Ну а вариант с 'field2=>other' потребует серьёзного парсера в случае введения дополнительных атрибутов поля...

> Нет, это ужасно

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

FIELD2 {{ fields=«other»; foo=1; bar=«asdf»; baz=42; }};

хотя миксин (или обобщение интерфейса) сюда просто необходим.

Да я ими и не прекращал интересоваться :)

значит этого недостаточно :-)

если тебе это не только для ОРМ-а надо, скажи где еще это нужно

Это в каком ORM сейчас так? Или в гипотетическом?

такой ОРМ можно в 200 строк самому написать (и чуть ли не в 50)

Я года три не щупал hibernate, там сделали нормальные JOIN'ы, постобработку загруженных данных, итераторы по массивам объектов? Можно ли определять автоматические геттеры-сеттеры?

Не знаю че у них там с ОРМами. Спрашивай у явистов.

> Ну и, собственно, есть ли адекватные фреймворки, где в одной нотации, во избежание дублирования, описываются как привязки БД, так и описания конкретных полей, скажем, для использования их в автоадминке?

Если я тебя понял, то это делается через рефлексию.

>> @DBField(«other») String field2;

Чего-то я к Яве привыкать начинаю... В смысле, что не возник на тему избыточной длины :D Всё же, это не ('field2' => 'other') ...

Еще не известно, где оверхед. В своем хэше ты дублируешь название поля, в аннотации — не дублируешь.

>если тебе это не только для ОРМ-а надо, скажи где еще это нужно

Короче, я выбираю Web-фреймворк под JVM. Как альтернативу своему PHP-шному BORS'у. Если найдётся готовый, удовлетворяющий основной части моих запросов в плане отсутствия синтаксической избыточности и наличия структурной гибкости - то буду использовать готовый. Нет - буду велосипедить свой, на основе принципов, отработанных на BORS. Вот под последний вариант пока и прощупываю синтаксические варианты.

У меня в порядке приоритета больше всего внимания (не обязательно затрат времени) требуют:
- Шаблоны (под это дело я отдельную тему завёл - http://www.linux.org.ru/forum/web-development/5350514)
- Описания объектов, в первую очередь - в привязках в ORM - соответственно, эта тема.
- Описание индивидуальной логики объектов - тут уже всё просто, синтакис может быть любым.

такой ОРМ можно в 200 строк самому написать (и чуть ли не в 50)

На PHP у меня примерно так и есть :) На Java дело усложняется тем, что я принципиально не люблю прямую работу с полями объекта, предпочитая работу с геттерами/сеттерами, а в самой Java нет простой возможности прописать автоматический геттер/сеттер, при вызове не существующего метода (х.з. как с этим в Scala, ещё не смотрел). Соответственно, если делать по уму - нужно писать генератор классов. Собственно, я собирался делать это в JBForth2, но отпала надобность, а работа достаточно объёмная и свободного времени на задачи столь низкого приоритета в последние годы нет :) А вот сейчас подумываю и об этом варианте снова.

> На Java дело усложняется тем, что я принципиально не люблю прямую работу с полями объекта, предпочитая работу с геттерами/сеттерами, а в самой Java нет простой возможности прописать автоматический геттер/сеттер, при вызове не существующего метода (х.з. как с этим в Scala, ещё не смотрел).

не понял, пиши подробнее

а какой-то маленький ОРМ (который был бы изучабелен до конца) мне было бы тоже интересно найти

Если я тебя понял, то это делается через рефлексию.

Через рефлексию я могу просто вызвать метод по имени. Мне же нужно, грубо говоря, такое:

class Class
{
    String title;
}

test = new Class();
test.setTitle("Hello");
System.out.println(test.Title());

А на самом деле, даже лучше что-то такое:

class Class
{
    HashMap data;
}

test = new Class();
test.setTitle("Hello"); // data("title") = "Hello";

> На Java дело усложняется тем, что я принципиально не люблю прямую работу с полями объекта, предпочитая работу с геттерами/сеттерами, а в самой Java нет простой возможности прописать автоматический геттер/сеттер, при вызове не существующего метода (х.з. как с этим в Scala, ещё не смотрел).

не понял, пиши подробнее

а какой-то маленький ОРМ (который был бы изучабелен до конца) мне было бы тоже интересно найти

>В своем хэше ты дублируешь название поля

Так не дублирую же :)

def main_table_fields = [«title», «create_time» => «UNIX_TIMESTAMP('Date')», «user_id», ...];

Сейчас у меня описания идут в таком духе. Даже более того:

def main_table_fields = [«message» => [«post» => «stripslashes», «field_title» => «Текст сообщения»], ...];

«post» - это указание на функцию-обработчик загруженных данных, «field_title» - заголовок поля для автоадминки и т.п.

> Через рефлексию я могу просто вызвать метод по имени. Мне же нужно, грубо говоря, такое:

Я опять не понимаю, нахрена это нужно и чем тебе мало рефлексии. Все это похоже на заморочки из дин. языков.

> def main_table_fields = [«message» => [«post» => «stripslashes», «field_title» => «Текст сообщения»] ]

class main_table_fields { @post(stripslashes) @field_title(«Текст сообщения») String message; };

да, не прошло и 20 лет после огромной рекламной компании, и на яве уже стало можно кое-что нормально писать :-)

Я опять не понимаю, нахрена это нужно

Дык, смотри. В моём случае я описил поля и потом их использую, как приведено выше.

В случае чистой Java я должен обязательно написать геттер/сеттер. Вместо одного слова в описании поля я должен писать ещё, как минимум, две функции. Т.е. вместо:

class ForumPost
{
    def main_table_fields = ['title', 'forum_id', 'user_id', 'message', 'post_time'];
}

я должен писать:

class ForumPost
{
    String title;
    String getTitle() { return this.title; }
    String setTitle(String title) { return this.title = title; }

    Integer forum_id;
    Integer getForumId() { return this.forum_id; }
    String setForumId(Integer forum_id) { return this.forum_id = forum_id; }

    Integer user_id;
    Integer UserId() { return this.user_id; }
    String setUserId(Integer user_id) { return this.user_id = user_id; }

    String message;
    String getMessage() { return this.message; }
    String setMessage(String message) { return this.message = message; }
}

Сколько времени уйдёт на написание первого варианта и второго? :)

И это ещё при самом примитивном сеттере. У меня же, скажем, сеттер ещё имеет второй параметр - требуется ли вносить изменение в БД или оно касается только временного изменения данных объекта. Осуществляется пометка поля объекта «изменено» при изменении, так, чтобы модифицированные объекты по окончании работы сами сохранялись и т.п. Вариант без автоматических геттеров/сеттеров сильно усложнят жизнь :)

Все это похоже на заморочки из дин. языков.

Безусловно :)

>@post(stripslashes)

Я боюсь, что такой записи ни один нынешний ORM не понимает :)

> Я боюсь, что такой записи ни один нынешний ORM не понимает

20 строк — и поймет

почему я и говорю про маленький ОРМ

>20 строк — и поймет

В варианте с прописанными выше готовыми сеттерами/геттерами - прокатит. Но такой кошмар и даром не нужен :)

Выходит, нужен вариант с кодогенерацией. А это в 20 строк уже не засунуть...

> Сколько времени уйдёт на написание первого варианта и второго? :)

Тут нормальный для явы способ — это генерация класса с геттерами-сеттерами по первому. Но разрюхать это, а затем написать требует время.

Я бы решил вопрос дешево и сердито — простой скрипт на перле, который по регулярным выражениям парсит один класс и генерит другой.

И это ещё при самом примитивном сеттере. У меня же, скажем, сеттер ещё имеет второй параметр - требуется ли вносить изменение в БД или оно касается только временного изменения данных объекта. Осуществляется пометка поля объекта «изменено» при изменении, так, чтобы модифицированные объекты по окончании работы сами сохранялись и т.п. Вариант без автоматических геттеров/сеттеров сильно усложнят жизнь :)

и вот тут мы приходим к ограничениям явы как языка

я бы предложил скалу, и заюзать унарные операторы

например, obj.field = ~~123 означает «временное» изменение, а вот obj.field = ^^123 означает персистентное, записываемое в базу

останется или нет тут маленький синтаксический оверхед — не знаю; вполне возможно для какого-то из изменений можно будет выкинуть унарные операторы, и писать просто obj.field = 123

> В варианте с прописанными выше готовыми сеттерами/геттерами - прокатит. Но такой кошмар и даром не нужен :)

без геттеров-сеттеров тоже прокатит. и 20 строк — это только один раз, а не в каждом классе.

>Я бы решил вопрос дешево и сердито — простой скрипт на перле, который по регулярным выражениям парсит один класс и генерит другой.

Это снова лишние сущности :)

> Осуществляется пометка поля объекта «изменено» при изменении, так, чтобы модифицированные объекты по окончании работы сами сохранялись

у явы есть одна проблема — у нее нет деструкторов, а финализаторы вызываются хрен знает когда

я не знаю, решена ли эта проблема в скале!

в C# IDisposable, так что там можно по выходу из блока вызывать деструктор и (надеюсь) в нем писать объект в БД

>у явы есть одна проблема — у нее нет деструкторов

Разве это проблема? :)

а финализаторы вызываются хрен знает когда

Когда ресурсов не хватает или время лишнее есть - тогда и вызываются :)

...

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

> Это снова лишние сущности

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

Да, обязательно чтобы геттеры-сеттеры не надо было записывать (obj.setField(123,PERSIST) гораздо хуже, чем obj.field=^^123)

> Разве это проблема?

Я не понял, ты согласен ручками прописывать obj.save_to_database(); obj=null; вместо простой «}» ?

Короче, как ты будешь сохранять объекты в БД?

>obj=null

Зачем? Как объект перестанет использоваться - оно само пройдёт.

Короче, как ты будешь сохранять объекты в БД?

Ну, в L2Fortress, например, они в базу сбрасывались или когда были не нужны, или периодически, по таймауту.

> L2Fortress

Интересно, а что это такое? Что-то связано с сетевыми играми?

Сколько времени уйдёт на написание первого варианта и второго? :)

Для написания геттеров унд сеттеров человечество 200 лет назад придумало IDE, коих легион

hash = ['item1', 'item2' => 'subst1', 1234];

Важно, чтобы можно было в синтаксисе смешивать хэш-подобные и массиво-подобные записи

А как это записывается на хаскеле? Может тогда легче будет аналог найти?

>Что-то связано с сетевыми играми?

Форк L2J, эмулятора MMORPG-сервера игры Lineage II.

А это было just-for-fun, или деньги тоже принесло?

Чистый Just-for-fun. Ну и, понятно, набор опыта по работе с достаточно нагруженными Java-серверами. Пока в других проектах не использовал, но лишним не будет.

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

А применять Scala ты тоже собираешься для фана или уже есть коммерческие планы? Просто я тут недавно прочитал книгу Programming in Scala. Язык мне очень понравился.

>А применять Scala ты тоже собираешься для фана или уже есть коммерческие планы?

И для фана и с коммерческими планами. Есть у меня идеи по паре-тройке серверных проектов. Да и об альтернативе PHP в области Web'а подумать нужно, где я его сейчас использую. Хрен знает, что с PHP-рынком через пару-тройку лет будет. Конечно, ещё Python в качестве возможного варианта рассматриваю, но это больше похоже на размен шила на мыло.

А принять участие в одном из таких проектов можно? Пусть ради фана и опыта.

Я пока только присматриваюсь издалека. Не факт, что чем-то конкретным до конца года займусь. А так, из того, чем во временем возможно, займусь, в порядке приоритета:
- Космическая стратегия на манер Imperion/OGame, но с иными идеологическими подходами.
- Web-фреймворк, если не найду чего-то готового, удовлетворяющего моим запросам
- Распределённый 3D-мир: http://www.linux.org.ru/forum/talks/1998739 - но там всё остановилось на разработчиках клиентской части. Я в этой области имею околонулевой на сегодняшние нормы скилл :)

Скорее всего, придётся доводить до ума и JBForth. Делать 2-ю версию, с кодогенерацией. Хотя scala отчасти отменяет потребность в нём, так что посмотрим ещё :)

Тогда я не понял, а что надо то?

Скажем, задать хэш в подобном виде:

hash = ['item1', 'item2' => 'subst1', 1234];

чтобы можно было в синтаксисе смешивать хэш-подобные и массиво-подобные записи.

Опиши подробнее.
Ну, в любом случае, в CL можно настроить синтаксис под себя.

ну, forth не недоязык

>ну, forth не недоязык

Я этого и не говорил :) Меня, как бы, можно назвать фанатиком этого языка ;)

написал письмо