можно тогда наверное сделать ещё определение <i8, i8> for i32

да

ой все

<i32>::cast(1i8): i8

impl Cast<i8, i8> for i32 { fn cast(x : i8) -> i8 { x + 32 } }

impl<T> . for T то и делает

имплементирует для всех типов

Cast<i8, i8> for i8, Cast<i8, i8> for i32, Cast<i8, i8> for String ...

да норм

надо с полифорфизмом реализовывать

для каждого типа разная реализация каста i8 -> i8

лол

struct Cast; trait CastT<A, B> { fn cast(A) -> B; } impl CastT<i8, i8> for Cast { fn cast(x : i8) -> i8 { x } } fn main() { let a: i8 = 2; let x: i8 = Cast::cast(a); println!("{}", x); }

так норм

хуя ты

похоже на элм

как заимплементить трейт для глобального скоупа?

а можно в трейте сказать where Self = Cast?

for Cast это оно и есть

не это impl

я про ограничение для трейта

кароч ваши тайпклассы не нужны интерфейсы ftw

struct Cast; impl Cast { fn cast(x : i8) -> i8 { x } } fn main() { let a: i8 = 2; let x: i8 = Cast::cast(a); println!("{}", x); }

да не

а лол

ето не то

бля, всегда читаю ftw как for the web

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

ладно реально много внимания уделено селфу

бля, всегда читаю ftw как for the web

лол

struct Cast<A, B> { a: PhantomData<A>, b: PhantomData<B> } impl Cast<i32, i64> { fn cast(x : i32) -> i64 { x.into() } }

?

struct Cast; impl Cast { fn cast(x : i8) -> i8 { x } } fn main() { let a: i8 = 2; let x: i8 = Cast::cast(a); println!("{}", x); }

это сюда

struct Cast<A, B> { a: PhantomData<A>, b: PhantomData<B> } impl Cast<i32, i64> { fn cast(x : i32) -> i64 { x.into() } }

эт мем

оно не работает

только что пробовал

работает

https://play.rust-lang.org/?gist=99ad78d0324fe04dc74c8f5c956a02a5&version=stable

use std::marker::PhantomData; struct Cast<A, B> { a: PhantomData<A>, b: PhantomData<B> } trait CastT<A, B> { fn cast(A) -> B; } impl Cast<i8, i8> { fn cast(x : i8) -> i8 { x } } impl Cast<i32, i64> { fn cast(x : i32) -> i64 { x.into() } } fn main() { let a: i8 = 2; let x: i8 = Cast::cast(a); let b: i32 = 31; let y: i64 = Cast::cast(b); println!("{} {}", x, y); }

https://play.rust-lang.org/?gist=f0e1a0e53d391a2e53e9ff79b63868bc&version=nightly

потому что

let a = 2; let x = <Cast<i8, i8»::cast(a); let b = 31; let y = <Cast<i32, i64»::cast(b);

по моему коду это должно было быть видно

мем

филиал фп в ооп

это случайность

не, я не против

чем больше знаешь - тем дороже стоишь

Парни, когда нибудь переводили/писали статьи об архитектуре? Как считаете, стоит ли переводить подобноые термины: Dependency Inversion Principle (DIP) Domain Model Data Access ?

вот вместо DIP никогда не видел чтобы ПИЗ писали)))

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

Вопрос по ES: Есть ли смысл хранить события каждого аггрегата в отдельной таблице?

Вопрос по ES: Есть ли смысл хранить события каждого аггрегата в отдельной таблице?

Каждого я думаю нет, но вот если какие то аггрегаты, использутся в разы чаще остальных их 100% выносим

Парни, когда нибудь переводили/писали статьи об архитектуре? Как считаете, стоит ли переводить подобноые термины: Dependency Inversion Principle (DIP) Domain Model Data Access ?

DIP не переводи, а принцип инверсии зависимостей вполне можно. Domain Model - модель предметной области. Data Access - объект доступа к данным если мы про DAO. Если сомневаешься - лучше не переводить.

Вопрос по ES: Есть ли смысл хранить события каждого аггрегата в отдельной таблице?

тут основной вопрос - зачем

если ты находишь это удобным - то почему бы и нет

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

Просто в статье много раз упоменается DIP и вот я думаю как то некрасиво выглядит это аббвеатура внутри русского текста, но кжадый раз принцип инверсии зависимостей возможно будет многовато

Каждого я думаю нет, но вот если какие то аггрегаты, использутся в разы чаще остальных их 100% выносим

я так понимаю что вы не в касандрах каких храните. да?

Просто в статье много раз упоменается DIP и вот я думаю как то некрасиво выглядит это аббвеатура внутри русского текста, но кжадый раз принцип инверсии зависимостей возможно будет многовато

норм

Просто в статье много раз упоменается DIP и вот я думаю как то некрасиво выглядит это аббвеатура внутри русского текста, но кжадый раз принцип инверсии зависимостей возможно будет многовато

а даш статью почитать?)

я так понимаю что вы не в касандрах каких храните. да?

пока нет, я недавно сменил команду, и сейчас ток одна модель реальзована по cqrs+es и то ее сделали прямо преед моим приходом. Она на mysql

а даш статью почитать?)

Аха, не думаю что она из песочницы выйдет)

или ты про оригинал?

1. про что статья, раз там много раз DIP (гескагоналка? сам DIP?) 2. хоть как)

пока нет, я недавно сменил команду, и сейчас ток одна модель реальзована по cqrs+es и то ее сделали прямо преед моим приходом. Она на mysql

я бы не стал хранить ивенты в разных табличках до того как мне это явно не понадобится

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

1. про что статья, раз там много раз DIP (гескагоналка? сам DIP?) 2. хоть как)

http://blog.ploeh.dk/2013/12/03/layers-onions-ports-adapters-its-all-the-same/

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

Почему?)

ну если не оценят будет повод наконецто создать свой блог и туда херачить))

ну так, опыт есть

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

на хабр постить желания нету вообще

Попробуй свой блог но как бы корпоративный. То есть де факто ты будешь туда писать один, но возможность черкануть будет у всех. Как подраскрутится чуток, может и желающие появятся. У тебя же все равно есть неммного аудитории, с телеги, с конференций с хабра того же) Мне кажется костяк "экспертов" даже с этой группы собрать небольшой, было бы интереснее чем в формате чата читать. То есть в блоге были бы статья(наброс) и тематическое обсудение в комментах)

Чат же многим нравится читать

а вот гексагон назвать шестигранником или как лучше?

гексагональной ее вроде все называют

можно и шестиугольной, если хочешь полностью перевести)

а вот гексагон назвать шестигранником или как лучше?

порты и адаптеры)

но не шестигранник (это стереометрия уже)

так вообще перфекто)

а вот гексагон назвать шестигранником или как лучше?

а почему не хочешь статью первоисточник перевести?)

порты и адаптеры)

там есть строчка что Гексагон не имеет ничего общего с гексагональной архитектурой)

а вот гексагон назвать шестигранником или как лучше?

гексагон не надо переводить

а почему не хочешь статью первоисточник перевести?)

видимо я ее не знаю)

да и эта маленькая и онятная показалась

там есть строчка что Гексагон не имеет ничего общего с гексагональной архитектурой)

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

ну так автор говорит) который кокберн

http://alistair.cockburn.us/Hexagonal+architecture

+1 за блог фесора

> The hexagon is not a hexagon because the number six is important, but rather to allow the people doing the drawing to have room to insert ports and adapters as they need, not being constrained by a one-dimensional layered drawing. The term ‘’hexagonal architecture’’ comes from this visual effect.

да, получается что автор заблуждался) ну напишу примечаание))

ну как, общее только название, количество граней не важно

но с такой же логикой он мог ее назвать равностороннетреуглоьной архитектурой))

ну видимо когда он схемки рисовал выходили шестиугольники) ну и они симетричные... там где-то в комментах было что он расстроился что спустя годы все же понял что "не симметричная концепция". Я не помню к чему там это было

на хабр постить желания нету вообще

че так?

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

http://telegra.ph/ он очень хорошо интегрируется с Instant view для телеги + можно паблик и туда постить ботом, очень красиво

че так?

да чет как-то ме