m.chota() returns chota

ты хочешь замокать результат метода? тогда делай val m = mock[YourImplicitClass]

аргументом в конструктор я это не могу передать уже

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

/*lib code*/ class Orig { def get(id: Int) = ??? } /*my code*/ implicit class OrigFix(o: Orig) { def getFixed(id: Int) = ??? } class UseCase(orig: Orig) { def foo = { orig.getFixed(123) } }

val m = mock[OrigFix] не работает?

так ведь у тебя же будет работать этот код. или что ты хочешь?

нет, т.к. new UseCase(mock[OrigFix]) скажет, что OrigFix это не Orig

так ведь у тебя же будет работать этот код. или что ты хочешь?

результат getFixed замокать

а что мешает тебе сделать class OtherFix(o:Orig){ def getFixed() } new UseCase(orig)(new OtherFix(orig))

или это опять не то, что ты хочешь?

тьфу, он же в параметрах не идет)

тут же явно не указан в этом классе

а нельзя написать mock[OrigFix with Orig] ?

я прост не знаю, что там

хотя опять же тип не тот будет

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

хотя опять же тип не тот будет

не зашло, да

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

идиоматичности хотел, а получился идиотизм %)

а если ты делаешь ew UseCase(mock[Orig])

что происходит

так он же имплисит метод хочет мокнуть, оригинал то какой смысл мокать? компилятор будет все равно искать имплисит внутри UseCase и найдет OrigFix

что происходит

вызывается OrigFix который импортится внутри UseCase. Т.е. я, конечно, могу замокать все методы Orig, которые там внутри вызываются, но уж больно их много

так он же имплисит метод хочет мокнуть, оригинал то какой смысл мокать? компилятор будет все равно искать имплисит внутри UseCase и найдет OrigFix

смысл мокать оригинал, в том, что у него тип нужный)

да по ходу, действительно, проще задекорировать Orig и декоратор отдельным параметром передать

так вот, если ты делаешь мок на оригинал, дальше компилятор не видит твоего имплисит метода?

видит, не-мокнутый

зависит от стадии мока, если она после линковки - уже не поможет) вызов уже будет разложен и слинкован

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

так я и буду интерфейс декоратора юзать уже)

вообще это камень в огород play, которые pull request приняли месяца полтора назад, а в релиз он еще не попал

а если в UseCase сунуть <: Orig

по сути твои имплисит класс эт совершенно другой класс

а если в UseCase сунуть <: Orig

но OrigFix никак не будет <: Orig соответствовать

переписать метод не переписывая исходник можно только манипуляцией байткодом

либо переписывай OrigFix, либо UseCase - таким образом чтобы он брал другой имплисит класс)

Вот чем-то таким и займусь, спасибо)

просто сделай class UseCase(orig: OrigFix)

и забудь)

\o/

релиз без RC3

чатик был про нейронки, линк дайте позязя

???

Урааа

Ура

Знакомые все лица подтягиваются :) ?

кто нибудь юзает vertx?

кто тут силен в type bound и всякой этой магии? я решил попробовать познать иии... как мне сделать это? class A[CC <: C[A[C], _]] class B[CC <: C[AA, _], AA <: A[CC]] class C[AA <: A[C[AA,BB]], BB <: B[AA, C[AA,BB]]] https://scalafiddle.io/sf/hj8YZPc/0

то есть вопрос даже такой. я должен этого хотеть? это нормальный кейс или я делаю что-то не так?

как-то все очень рекурсивненько

ну если первый зависит от третьего, второй от первого, а третий от первого и второго, то как это записать?

однозначно что-то делаешь не так type-level computations вообще опасные, а уж в не предназначенном для этого языке...

да я вот тоже начал думать, что вообще я зря все это затеял :)

а что сделать-то хочешь? (итоговый кейс)

некую гибкую валидацию в компайл тайме на уровне типов

ну на самом деле можно и проще, но будет не так гибко

я пытаюсь абстрактно описать предметную область блокчейна. Есть транзакция, блок и блокчейн. Есть транзакция типа блокчейна (как тип A в моем примере), блок включает в себя транзакции типа блокчейна (тип B), и сам блокчейн с этими типами транзакции и блока (тип C)

ну вот это я и хочу написать

я пытаюсь абстрактно описать предметную область блокчейна. Есть транзакция, блок и блокчейн. Есть транзакция типа блокчейна (как тип A в моем примере), блок включает в себя транзакции типа блокчейна (тип B), и сам блокчейн с этими типами транзакции и блока (тип C)

я могу ошибаться, но мб вот этот гайд как раз что нужно http://danielwestheide.com/blog/2013/02/13/the-neophytes-guide-to-scala-part-13-path-dependent-types.html

спасибо, прочту

я пытаюсь абстрактно описать предметную область блокчейна. Есть транзакция, блок и блокчейн. Есть транзакция типа блокчейна (как тип A в моем примере), блок включает в себя транзакции типа блокчейна (тип B), и сам блокчейн с этими типами транзакции и блока (тип C)

Скажи пожалуйста ,Ты по каким материалам осваиваешь данную тематику , не подскажешь ?

я сам упарываюсь)

Ну основа то какая

Давайте какую-нибудь библиотечку сделаем полезную нашей юзергруппой

я не понимаю вопроса) я работаю в wavesplatform и я решил попробовать изучить/применить type-level магию в нашем деле

я не понимаю вопроса) я работаю в wavesplatform и я решил попробовать изучить/применить type-level магию в нашем деле

Я про блокчейн

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

я не понимаю вопроса) я работаю в wavesplatform и я решил попробовать изучить/применить type-level магию в нашем деле

:( мы друзья в ликедине))

эм, у меня там много кого ?

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

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

Я про блокчейн

ну тогда вероятно ответ - по сугубо моему опыту

на вики неплохая вводная https://ru.wikipedia.org/wiki/%D0%A6%D0%B5%D0%BF%D0%BE%D1%87%D0%BA%D0%B0_%D0%B1%D0%BB%D0%BE%D0%BA%D0%BE%D0%B2_%D1%82%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%B9

:) ну на более глубоком уровне

Может блоги есть какие тематические

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

вот описание nxt (похоже на waves) http://wiki.nxtcrypto.org/wiki/Whitepaper:Nxt

Спасибо большое

на самом деле есть наверное много хороших материалов по этой теме, но я особо не искал)

насчет криптовалют есть учебная реализация на скале кстати

https://github.com/input-output-hk/Scorex

да, и там все плохо. очень. совсем

я поспорил с одним из ее авторов, что напишу часть этой мешанины за выходные проще и понятнее :D проще и понятнее с type-level это я конечно загнул, но хотя бы корректнее будет

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

Sergey Tolmachev я бы сюда заглянул http://gigiigig.github.io/tlp-step-by-step/introduction.html

я уже великолепно решил проблему с помощью path-dependent types, очень рад этому решению)

спасибо, до этого тоже как-нибудь доберусь

Можно пример

ну в итоге я A и B перенес в C и все стало гораздо проще

trait BlockChain { abstract class BlockChainBlock extends Validable with Signable { type Id } abstract class BlockChainTransaction extends Validable with Signable with StateChangeReason type T <: BlockChainTransaction type B <: BlockChainBlock type A <: BlockChainAccount abstract class BlockChainAccount(val publicKey: Array[Byte], val privateKey: Option[Array[Byte]]) abstract class BlockChainAddress(val address: Array[Byte]) trait BlockChainSignedTransaction[V] extends BlockChainTransaction with Signed[T, V, Signature[V]] trait BlockChainSignedBlock[V] extends BlockChainBlock with Signed[B, V, Signature[V]] type TransactionValidator = AggregatedValidatorOnBlockchain[this.type, BlockChainTransaction, TransactionValidationError[this.type]] type BlockValidator = AggregatedValidatorOnBlockchain[this.type, BlockChainBlock, BlockValidatorError[this.type]] def genesis: BlockChainBlock def txValidator: TransactionValidator def blockValidator: BlockValidator }

как-то так. но я оно еще в процессе

path-dependent types = нестатические вложенные классы

@fomkin что будет с юзергруппом то

Решил ?