хотя как-то костыльно, по моему скромному мнению

разве scope не переписывается в try finally?

Кстати, один я заметил значительное изменение отношение людей к D? Что на Лоре что на OpenNet, что даже на Хабре? https://habrahabr.ru/post/337098/#comment_10398996 Просто еще год назад все говном исходили, а пока только Гоферы везде где можно поливаются, а про Ди очень часто с большим уважением

Что то не уловил связи между твоим сообщением и ссылкой

Там про Д вообще не упоминается

может там про Го?

Там про Go

Отношение к go впринципе и не менялось, но все же при чем тут отношение к D непонятно :)

Ну раньше о Ди куда хуже писали

Не, о нем пишут постоянно одно и то же - Д не нужен/мало инструментов. Сам язык никто еще не критиковал.

Хотя если копнуть в него глубже, там есть за что )

что почитать про использование интерфейсов как типов?

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

строка 11 http://paste.code123.org/27ccfbd5-2ff6

что почитать про использование интерфейсов как типов?

паттерны проектирования

Везде где ты хочешь в коде абстрагироваться от того, в mysql у тебя лежат данные или в postgresql, надо завязываться только на интерфейс

либо банда 4х, либо head first

То есть почти всегда :)

В своей программе тебе должно быть абсолютно наплевать, куда именно ходит объект dataBase

https://www.litres.ru/dzhon-vlissides/priemy-obektno-orientirovannogo-proektirovaniya-patterny-proektirovaniya-16419747/

https://www.ozon.ru/context/detail/id/20216992/

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

Вот у меня есть: class Factory { IDatabase getDbType(string dbname) { if(dbname == "mysql") return new PostgreSQL(); if(dbname == "pg") return new MySQL(); else return null; } } и Factory fc = new Factory(); IDatabase dataBase = fc.getDbType("pg"); Как мне узнать тип того что вернет getDbType?

Тебе не нужно это знать

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

Тоесть уже совсем никак и это и не нужно. Верно?

Да.

угу, понял, спасибо

Но как всегда, в реальности тебе все же может это быть нужно, иначе очень тяжко разрабатывать )

и тогда как?

Например если ты тянешь из базы 1000000 записей, то в pg есть курсоры, которые могут эффектно наложиться на Ranges и оптимально использовать память, а в mysql нету.

Тогда начинают изобретать свистелки и перделки в интерфейсе, например какой-нибудь метод bool hasLazyQueries() А в коде ты дергаешь этот метод, но опять же об источнике ничего не знаешь.

тогда лучше что бы БД отдавали Range, и внутри юзали свои способы доступа

Юзай Монго))

Ну в случае mysql этот range будет бутафорией, которая просто выгружает все записи в память приложения а потом уже по ним бегает

Было бы прикольно сделать интерпретируемый язык с кириллическими лексемами ))

1С

Ну это все же больше комбайн, который трудно ставить на линукс и поддерживать. И он проприетарный

Было бы прикольно сделать интерпретируемый язык с кириллическими лексемами ))

Нет

Какой, хорошо говорящий по русски человек спокойно переносит неправильные склонения, падежи, числительные?

Добавить туда Ъ-нити

Будет что-то вроде 'покупай хороший кофта'

Английский для нас не родной, поэтому многие спокойно относиться к неправильному употреблению его в коде

И это идеально, иначе отвлекало бы

Да, склонения и падежи можно попробовать впилить в дизайн языка ?

Да, склонения и падежи можно попробовать впилить в дизайн языка ?

Вот это задачка))

Ключевые матерные слова

Вместо for "нах"

Офигенная песочница получилась бы

Вместо include/import "хуйнуть"

Эх ябпокодил

Да, склонения и падежи можно попробовать впилить в дизайн языка ?

Это Perl. Там $x и @x как падежи примерно.

Эх ябпокодил

https://yopta.space/ навалом такого

Ну там просто транслятор в javascript, недостаточно фундаментально

Должен быть свой байткод, и какая то философия

Например "язык импортозамещения"

Вместо for "нах"

По идее, раз dlang понимает юникод, он может в русскоязычные идентификаторы

Хотя не факт

Вот Nimrod точно может

По идее, раз dlang понимает юникод, он может в русскоязычные идентификаторы

индентификаторы да

Тогда начинают изобретать свистелки и перделки в интерфейсе, например какой-нибудь метод bool hasLazyQueries() А в коде ты дергаешь этот метод, но опять же об источнике ничего не знаешь.

Так, погоди, ну а как мне узнать с какой БД я работаю в данный момент? Это можно как-то сделать? или все. появился интерфейс и тип БД превратился в черный ящик

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

А если в целом говорить про интерфейсы, то они были изобретены ради избавления от вакханалии множественного наследования, которая получилась в C++

Тогда начинают изобретать свистелки и перделки в интерфейсе, например какой-нибудь метод bool hasLazyQueries() А в коде ты дергаешь этот метод, но опять же об источнике ничего не знаешь.

Так, мне это получается в каждом классе реализующем интерфейс добавлять?

что добавлять?

какой-нибудь метод bool hasLazyQueries()

все зависит от архитектуры

ERROR: S client not available

если в интерфейсе есть такой метод, то да)

и дальше как его юзать. вот предположим я создал фабрику классов и фабрика возврщает мне используемую БД: Factory fc = new Factory(); IDatabase dataBase = fc.getDbType("pg");

дальше типа: if(database.hasLazyQuiries()) { ... }

перед тобой вообще какая задача стоит?)

пока есть время хочу разобраться

с чем?)

с интерфейсами

ну и паттернами вообще

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

ну это понятно, мне реальный кейс нужен где они нужны. просто пока получается если я работаю с PG то проще вообще без интерфейсов все делать. Получается только абстрактная ситуация вроде: "БД может меняться"

ну например, логирование

ты создаешь интерфейс Logger, где описаны, например, методы notice, warning, error, critical

и везде, где нужно логирование ты говоришь: «дайте мне объект, который реализует интерфейс Logger, я с его помощью буду лог вести»

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

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

а перегрузку разве при при реализации интерфейса нужно делать? просто в примере на Java пишут так: public class ClientLinuxImpl implements Client{ @Override public String getTargetOS() { return "Gentoo Linux"; } }

А если в целом говорить про интерфейсы, то они были изобретены ради избавления от вакханалии множественного наследования, которая получилась в C++

Каким боком? В плюсах они тоже давным давно были.

Каким боком? В плюсах они тоже давным давно были.

кто были?

кто были?

Интерфейсы. Не понимаю как они проблемы множественного наследования решают.

не было никогда в C++ интерфейсов, их роль там может выполнять абстрактный класс)

но наследоваться можно от любых классов, поэтому для C++ характерна проблема ромбовидного наследования

поэтому в большинстве улучшателей C++ не существует множественного наследования, но есть интерфейсы, которые ограниченно выполняют эту задачу

а перегрузку разве при при реализации интерфейса нужно делать? просто в примере на Java пишут так: public class ClientLinuxImpl implements Client{ @Override public String getTargetOS() { return "Gentoo Linux"; } }

а с этим то что?

Это переопределение, перегрузка - это overload

а в ди это нужно то что выше?

Еще в книжке пишу: Суть фабрики заключается в том, что специальный "фабричный" класс будет создавать и возвращать класс того или иного типа в зависимости от определенного условия. То есть если мы передадим туда, к примеру, "mysql", то он создаст и вернет нам экземпляр для работы с MySQL, если с PostgreSQL то экземпляр для работы с PostgreSQL фраза корректна?

И корректна ли фраза: IDatabase dataBase = fc.getDbType("pg"); // передаем в интерфейс тип БД с который мы работаем в данный момент

Не, не очень

а что не так?

Скорее так: "создаем экземпляр класса, который реализует данный интерфейс"

Но лучше подожди, пока ответит кто поумней

Скорее так: "создаем экземпляр класса, который реализует данный интерфейс"

по идее мы его a фабрике создаем...