type superSlice slice

типа такое

type superSlice slice

type MyStruct []Т или твой тип

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

да, но можно свой тип

расширить слайс это только добавить свои методы

а я хочу создавать такой тип который может принять все (как generic) можно такое ?

а я хочу создавать такой тип который может принять все (как generic) можно такое ?

тогда можно сделать слайс из any

но это кончено

лучше как Илья предлагает - слайс из конкретного типа и этот тип задать параметром

Привет всем хочу наследоваться от slice что бы расширить его. Как можно такое сделать ?

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

короче нас ждут теперь интерфейсы: Makable, Appendable, Rangable

Slicable

иначе пизда

Stackable

короче нас ждут теперь интерфейсы: Makable, Appendable, Rangable

DotNet какой-то получается.

Concurrentable

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

вангую, в ближайшие года 3 появится

да, наслаждайтесь гошечкой, пока она еще маленькая и уютная. Хотя, наверное, уже поздно.

ждем появления магических методов)

а по сути, ну можно свой Make сделать на таком слайсе, свой Append и тд, но чем фактически будет отличаться от возможности дать обращаться built in функциями непонятно

ждем появления магических методов)

это уже рефлексия

а по сути, ну можно свой Make сделать на таком слайсе, свой Append и тд, но чем фактически будет отличаться от возможности дать обращаться built in функциями непонятно

свой make будет не такой. Т.к. "настоящий" make работает со слайсом любого типа, с мапой любого [типа]типа. Написать такое же не получится, т.к. языковых средств Go недостаточно для внедрения в сам Go новых конструкций.

ну тут тоже

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

А я вот мечтаю о каналах с изменяющимся размером.

А я вот мечтаю о каналах с изменяющимся размером.

зачем

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

канал не предназначен для хранения данных

но размер же у него зачем-то есть?

а зачем увеличивать размер канала?

размер и у буфера есть

а зачем увеличивать размер канала?

Такая сложилась ситуация в рантайме, например.

Такая сложилась ситуация в рантайме, например.

извиняюсь, неправильно написал

Допустим, я хочу, чтобы пишущие в канал го-рутины не простаивали. Как я могу это обеспечить? Никак.

прохладная мотивация и xy problem в целом

Допустим, я хочу, чтобы пишущие в канал го-рутины не простаивали. Как я могу это обеспечить? Никак.

создать очередь?

очередь - это уже внешний инструмент. В Го ж нет очередей встроенных. Точнее есть - но это как раз канал

Буферизированный канал создается с конкретным лимитом, который зависит от маскимальной вместимости вашего пайплайна. Если capacity изменяется, то смысл использовать каналы вообще?

А что тогда использовать вместо каналов?

А что тогда использовать вместо каналов?

очереди

буферизованный канал по сути и есть просто очередь с сахарком

по поводу этого можно почитать про worker pool, чтобы не допускать простоя горутин

для чего канал с изменяющимся буфером? чтобы что?

для чего канал с изменяющимся буфером? чтобы что?

Чтобы не делать его излишне большим, когда он не нужен, но и иметь возможность его расширить, если все-таки надо.

нуууууууу

а когда он нужен большой?

в чем цель увеличивать? я не очень понимаю

а когда он нужен большой?

когда внезапно 10 тысяч клиентов от сервера что-то попросили.

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

А там в любом случае гарантии нет. .

есть, положил во внешнюю очередь - четенько уже в отдельных процессах обработку отстроил

тут крякнулся твой процесс веб сервера - прощай внутренняя очередь

тут крякнулся твой процесс веб сервера - прощай внутренняя очередь

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

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

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

но емейлы не уйдут, а ты уже отдал 100500 страниц, что ща вам емейл с важными данными придет

тут крякнулся твой процесс веб сервера - прощай внутренняя очередь

ну для такого есть кафка

так да

я об чем говорю

вообще вместо буферизированного канала есть мьютекс и слайс =)

но емейлы не уйдут, а ты уже отдал 100500 страниц, что ща вам емейл с важными данными придет

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

так а что ты откладываешь в очередь в таком случае?

я не понимаю, приведи пример

В очередь мы складываем запросы клиентов.

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

В очередь мы складываем запросы клиентов.

зачем

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

тем более что наверняка она так и так будет что-то из канала ждать

В очередь мы складываем запросы клиентов.

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

чтобы что?

распухает количество го-рутин и распухает количество используемой ими памяти. А так - горутина, принимающая запрос от клиента, оставляет в канале структуру-запрос и благополучно завершается, не занимая больше память.

у тебя уже горутина создана

или ты хочешь свой веб сервер написать?

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

свой хттп сервер

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

как это объясняет хоть что либо из того о чем я говорю и спрашиваю?

свой хттп сервер

нет, хттп-сервер стандартный.

у тебя уже горутина создана

го-рутина, принимающая запрос, и го-рутина, обрабатывающая запрос - это разные го-рутины.

ну а что ты хочешь? приходит запрос, у тебя запускается твой хэндлер, на него УЖЕ (!) выделена горутина