Здравствуйте, c-smile, Вы писали:
CS>var s1 = s[6..12]; CS>var s2 = s[..5]; CS>var s3 = s[6..];
CS>Какие будут у народа мысли по поводу идеологической чистоты этого CS>безобразия?
Ну, прямо как в Python.
Только там двоеточие не горизонтально, а вертикально ориентировано
Здравствуйте, burbaka, Вы писали:
B>Здравствуйте, c-smile, Вы писали:
CS>>var s1 = s[6..12]; CS>>var s2 = s[..5]; CS>>var s3 = s[6..];
CS>>Какие будут у народа мысли по поводу идеологической чистоты этого CS>>безобразия?
B>Ну, прямо как в Python. B>Только там двоеточие не горизонтально, а вертикально ориентировано
Только ещё надо завернуть индексацию в кольцо, ввести отрицательные индексы и обработку невалидных интервалов
Здравствуйте, R.K., Вы писали:
RK>Здравствуйте, burbaka, Вы писали:
B>>Здравствуйте, c-smile, Вы писали:
CS>>>var s1 = s[6..12]; CS>>>var s2 = s[..5]; CS>>>var s3 = s[6..];
CS>>>Какие будут у народа мысли по поводу идеологической чистоты этого CS>>>безобразия?
B>>Ну, прямо как в Python. B>>Только там двоеточие не горизонтально, а вертикально ориентировано
RK>Только ещё надо завернуть индексацию в кольцо, ввести отрицательные индексы и обработку невалидных интервалов
"завернуть индексацию в кольцо" а зачем? я что-то глобальное пропустил?
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, R.K., Вы писали:
RK>>Здравствуйте, burbaka, Вы писали:
B>>>Здравствуйте, c-smile, Вы писали:
CS>>>>Какие будут у народа мысли по поводу идеологической чистоты этого CS>>>>безобразия?
B>>>Ну, прямо как в Python. B>>>Только там двоеточие не горизонтально, а вертикально ориентировано
RK>>Только ещё надо завернуть индексацию в кольцо, ввести отрицательные индексы и обработку невалидных интервалов
CS>"завернуть индексацию в кольцо" а зачем? я что-то глобальное пропустил?
Это я просто изобрел несуществующую фичу в Питоне
>>> a=[0,1,2,3,4]
>>> a[-4:4] # так можно
[1, 2, 3]
>>> a[4:-4] # и так можно, но вернет пустой список
[]
И вообще, индексация списков выглядит не самым эффективным способом их обработки. Или это не связные списки?
Здравствуйте, c-smile, Вы писали:
CS>Это обычные векторы или индексируемые (целым числом) коллекции. CS>Понятно что для hash map это уже не подходит.
Для хэш мэпа, получается, нужно делать двухуровневый слайснг:
1. Мы получаем диапазон значений ключей в слайс-виде
2. Мы отдаем этот диапазон в коллекцию, и получаем обратно диапазон значений.
Т.е. получается, что "5.." и "1..2" — это полноценные объекты, представляющие список значений ключей. Это означает, что можно скармливать в телефонную книгу такие выражения:
Здравствуйте, Sinclair, Вы писали:
S>phonebook["Иванов".."Петров"] S>phonebook["Булгаков"..] S>Ну как, вполне безумно?
Я не понимаю, как из "Иванов".."Петров" можно (однозначно) построить список значений. Разве сделать вместо строк специальные объекты с перегруженной операцией __slice__, но полезность вообще для меня сомнительна Вот для числовых индексов это чрезвычайно удобно.
Здравствуйте, Кодёнок, Вы писали: Кё>Я не понимаю, как из "Иванов".."Петров" можно (однозначно) построить список значений.
Не, список значений надо делать из списка ключей, фильтруя по предикату key>="Иванов" && key<= "Петров".
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Кодёнок, Вы писали: Кё>>Я не понимаю, как из "Иванов".."Петров" можно (однозначно) построить список значений. S>Не, список значений надо делать из списка ключей, фильтруя по предикату key>="Иванов" && key<= "Петров".
Технически это возможно. Практически надо ли?
Принимая во внимание
1) array.sort([func]) наличествует и в нем можно использовать custom sort func.
2) Скорее всего в язык и рантайм будет "вмурован" SQLite (дискутируется).
По поводу последнего вот кстати вопрос: нужно придумать способ расширения синтаксиса
другими языками (если сие в принципе возможно и нужно).
Т.е. хотелось бы например (и технически возможно) иметь конструкции вида:
var val = ...;
var rs = db_connection <- select one,two from tbl where one = @val;
хотя по мне, например, и так тоже нормально ( и меньше неоднозначности ):
var rs = db_connection.queryf( "select one,two from tbl where one = %s", val);
Здравствуйте, c-smile, Вы писали:
CS>2) Скорее всего в язык и рантайм будет "вмурован" SQLite (дискутируется).
CS>По поводу последнего вот кстати вопрос: нужно придумать способ расширения синтаксиса CS>другими языками (если сие в принципе возможно и нужно).
Здравствуйте, c-smile, Вы писали: CS>Принимая во внимание CS>1) array.sort([func]) наличествует и в нем можно использовать custom sort func.
Это просто попытка поднять слайс на более высокий уровень абстракции.
В нем предполагается, что слайсить можно любую коллекцию, если она индексируется упорядоченными ключами.
Например, массив — это частный случай коллекции, индексированной целыми числами.
CS>2) Скорее всего в язык и рантайм будет "вмурован" SQLite (дискутируется).
Ну, слайсинг к языку запросов прямого отношения не имеет. По поводу вмуровывания запросов в язык, имхо, лучшее достижение — LINQ (C#3).
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, c-smile, Вы писали: CS>>Принимая во внимание CS>>1) array.sort([func]) наличествует и в нем можно использовать custom sort func. S>Это просто попытка поднять слайс на более высокий уровень абстракции. S>В нем предполагается, что слайсить можно любую коллекцию, если она индексируется упорядоченными ключами. S>Например, массив — это частный случай коллекции, индексированной целыми числами.
В принципе языки семейства JavaScript имеют только одну коллекцию.
Технически, например, JScript (в IE) использует hash tables и для массивов тоже (эдакий sparse array).
Т.е. ranges там не так эффективны как хотелось.
Если же говорить про ranges для произвольных ключей то нужно еще как-то
уметь задавать фуннкцию отношения (less) что сильно утяжеляет всю конструкцию.
Когда я говорю про SQLite то предполагается что задачи типа a["one"..."three"]
могут эффективнее всего делаться в нем потому как 1) SQLite имеет механизм in-memory tables
2) SQLite/scripting позволяет описывать функции less в самом скрипте.
Т.е. select v from tbl where v >= "one" and v < "three"
может звать custom функцию.
CS>>2) Скорее всего в язык и рантайм будет "вмурован" SQLite (дискутируется). S>Ну, слайсинг к языку запросов прямого отношения не имеет. По поводу вмуровывания запросов в язык, имхо, лучшее достижение — LINQ (C#3).
Это уж слишком круто. Так далеко (в т.ч. по объему требуемого кодирвания) смысла идти особого нет я думаю.
Скорее всего я остановлюсь на традиционном
var rs = db_connection.queryf( "select one,two from tbl where one = %s", val);
Здравствуйте, Andrei N.Sobchuck, Вы писали:
CS>>По поводу последнего вот кстати вопрос: нужно придумать способ расширения синтаксиса CS>>другими языками (если сие в принципе возможно и нужно).
ANS>В Tcl (tclodbc), например, так сделано:
ANS>
ANS>% database connect db "DRIVER=SQL Server;SERVER=dbs1;DBQ=mydb"
ANS> db
ANS>% db "select id from employees where salary < 1000"
ANS> {222 333 444}
ANS>% db disconnect
ANS>
Хммм... насколько я вижу это стандартный способ когда
запрос это строка в терминах host языка (script per se)...
Или я чего не разглядел?
Здравствуйте, c-smile, Вы писали:
ANS>>В Tcl (tclodbc), например, так сделано:
ANS>>
ANS>>% database connect db "DRIVER=SQL Server;SERVER=dbs1;DBQ=mydb"
ANS>> db
ANS>>% db "select id from employees where salary < 1000"
ANS>> {222 333 444}
ANS>>% db disconnect
ANS>>
CS>Хммм... насколько я вижу это стандартный способ когда CS>запрос это строка в терминах host языка (script per se)... CS>Или я чего не разглядел?
Теперь уже не знаю насколько это соотносится с тем, что ты хотел
В tclodbc всё зависит от первого параметра. Если это не команда (как "disconnect"), то считается, что это SQL запрос.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Кодёнок, Вы писали: Кё>>Я не понимаю, как из "Иванов".."Петров" можно (однозначно) построить список значений. S>Не, список значений надо делать из списка ключей, фильтруя по предикату key>="Иванов" && key<= "Петров".
Только для таких выкрутасов нуже лучше использовать сортированные массивы или деревья. Но не как не хэш-таблинцы.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>Только для таких выкрутасов нуже лучше использовать сортированные массивы или деревья. Но не как не хэш-таблинцы.
Дык это уже implementation-specific. Мне такие фичи тем и нравятся, что пишешь некоторый код, а уж потом натравливаешь профайлер. Если результат тебя не устраивает — заменяешь хэшмэп сортированным массивом или деревом.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Дык это уже implementation-specific. Мне такие фичи тем и нравятся, что пишешь некоторый код, а уж потом натравливаешь профайлер. Если результат тебя не устраивает — заменяешь хэшмэп сортированным массивом или деревом.
А я вот сторонник идеи, что не гоже встраивать несоотвествующую функциональность в классы. Ну, не рассчитаны хэш-таблицы на хранение отсортированных элементов. Стало быть и не должны предявлять требования сравниваемости элементов на больше/меньше. Например, шрифт нельзя сравнить на больше/меньше, так что же мне теперь его в хэш-таблицу не помещать?
Пусть поиск диапазонов будет там, где это действительно нужно. Понадобится — сменишь контэйнер.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>А я вот сторонник идеи, что не гоже встраивать несоотвествующую функциональность в классы. Ну, не рассчитаны хэш-таблицы на хранение отсортированных элементов. Стало быть и не должны предявлять требования сравниваемости элементов на больше/меньше. Например, шрифт нельзя сравнить на больше/меньше, так что же мне теперь его в хэш-таблицу не помещать?
Да, пожалуй верно.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.