кажется, если есть мембер, экстеншен недостижим)

Из Java вполне достижим

Из Java вполне достижим

ну конечно

кажется, если есть мембер, экстеншен недостижим)

Вообще это плохо. Один человек написал библиотечку с экстеншенами к другой библиотечке, потом в другой библиотечке другой человек сделал мемберы с теми же именами и прощай экстеншены. Их теперь никак не вызовешь, если не переделывать библиотечку с экстеншенами.

Вообще это плохо. Один человек написал библиотечку с экстеншенами к другой библиотечке, потом в другой библиотечке другой человек сделал мемберы с теми же именами и прощай экстеншены. Их теперь никак не вызовешь, если не переделывать библиотечку с экстеншенами.

У меня есть похожая запара: очень хочется member val перекрыть extension-var'ом.

похоже на design flaw

Вообще это плохо. Один человек написал библиотечку с экстеншенами к другой библиотечке, потом в другой библиотечке другой человек сделал мемберы с теми же именами и прощай экстеншены. Их теперь никак не вызовешь, если не переделывать библиотечку с экстеншенами.

Ну можно же не топ левел сделать экстеншен

Ну можно же не топ левел сделать экстеншен

Никакой разницы. Все экстеншены от ресивера отвалятся, как только у него появятся перекрывающие мемберы. Притом наглухо и без права воскрешения.

и та к и так

Разучился я в конец писать на яве, но все-таки запустил. Для топ левел расширения все работает

похоже на design flaw

Ну ситуация такая: можно читать значение, а если в области видимости есть транзакция, то ещё и писать.

Разучился я в конец писать на яве, но все-таки запустил. Для топ левел расширения все работает

Да в яве всё ок.

Разучился я в конец писать на яве, но все-таки запустил. Для топ левел расширения все работает

код, я кидал где не работает

Практически тоже самое, только строка в ресивере и все работает

Может я не правильно вопрос понял. В джаве работает

Может я не правильно вопрос понял. В джаве работает

В котлине как в джве

я кидал код с котлин кодом

Аа. Ну это другое

вот проблема

Никакой разницы. Все экстеншены от ресивера отвалятся, как только у него появятся пееркрывающие мемберы. Притом наглухо и без права воскрешения.

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

А кек в котлине нельзя вообще вызвать экстеншен эксплиситно

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

А кек в котлине нельзя вообще вызвать экстеншен эксплиситно

Судя по всему, нет. qualified вызовов для екстеншенов не предусмотрено.

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

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

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

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

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

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

любая иде покажет @Override не?

любая иде покажет @Override не?

я так и написал

любая иде покажет @Override не?

> только умная иде тебе подскажет что тут что-то не так

любая иде покажет @Override не?

так и идея подскажет что екстеншен не вызывается

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

Ну вот ты расширил функционал. Классический пример - map для Iterable в котлине сделан на экстеншенах. Потом кто-то другой добавил map в реализацию Iterable и код экстеншена недоступен.

(подсветка)

так и идея подскажет что екстеншен не вызывается

Нет, не подскажет, если на момент написания экстеншена он не перекрыт

Ну вот ты расширил функционал. Классический пример - map для Iterable в котлине сделан на экстеншенах. Потом кто-то другой добавил map в реализацию Iterable и код экстеншена недоступен.

ну это ооп детка, ты не можешь довать такое же поведение, ты можешь его переопределить

Ну вот ты расширил функционал. Классический пример - map для Iterable в котлине сделан на экстеншенах. Потом кто-то другой добавил map в реализацию Iterable и код экстеншена недоступен.

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

Намного проще когда данные и функции разделены, нет никакой мутоты с наследованием

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

С наследованием ты всё равно можешь до super достучаться. Тут же код экстеншена вообще недоступен никак

Нет, не подскажет, если на момент написания экстеншена он не перекрыт

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

С наследованием ты всё равно можешь до super достучаться. Тут же код экстеншена вообще недоступен никак

тут согласен

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

Ок. Я пишу экстеншен на ресивер из сторонней библиотеки. В моей версии библиотеки он не перекрыт. Потом овнер библиотеки, который слыхом обо мне не слыхивал, добавляет перекрывающих мемберов, у него тоже ничего не конфликтует. Я обновляю версию библиотеки и ловлю грабли на ровном месте.

Ок. Я пишу экстеншен на ресивер из сторонней библиотеки. В моей версии библиотеки он не перекрыт. Потом овнер библиотеки, который слыхом обо мне не слыхивал, добавляет перекрывающих мемберов, у него тоже ничего не конфликтует. Я обновляю версию библиотеки и ловлю грабли на ровном месте.

импорты ?

импорты ?

И как они помогут?

Ок. Я пишу экстеншен на ресивер из сторонней библиотеки. В моей версии библиотеки он не перекрыт. Потом овнер библиотеки, который слыхом обо мне не слыхивал, добавляет перекрывающих мемберов, у него тоже ничего не конфликтует. Я обновляю версию библиотеки и ловлю грабли на ровном месте.

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

И как они помогут?

если пекеджы различаются то да

или разные разрабы пишут одинаковые классы под одинаковыми пакетами, с одинаковыми именами ?

если пекеджы различаются то да

Всё равно не помнимаю, как мне импорты помогут сделать код экстеншенов доступным. Только их переименование поможет. А переименовать я тоже не могу, так как это сломает код тех, кто мой код использует.

короче это @flood

Всё равно не помнимаю, как мне импорты помогут сделать код экстеншенов доступным. Только их переименование поможет. А переименовать я тоже не могу, так как это сломает код тех, кто мой код использует.

у вас две разные библиотеки ? Разные разрабы, разные либы

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

С классами эта проблема решается путём выноса API

С классами эта проблема решается путём выноса API

я напсал класс Point, и друг написал класс Point, причем оба в пакете mega.liba/. Удачи

abstract class AbstractClass<T> { companion object{ private val stuffy: Stuff<T> = Stuff.create() } } подскажите что не так написал, пишет что unresolved reference в компаньоне

я напсал класс Point, и друг написал класс Point, причем оба в пакете mega.liba/. Удачи

Ну тут jar hell, он в kotlin так же есть. Только в kotlin, походу, ещё extension hell добавится, притом даже без коллизий имён по пакетам

Ну тут jar hell, он в kotlin так же есть. Только в kotlin, походу, ещё extension hell добавится, притом даже без коллизий имён по пакетам

о боже, я понял. Проблема архитектуры - это проблема архитектора а не яп.

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

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

Ну-ка, как там алиас-то делается для экстеншена, если есть перекрывающий мембер на ресивере?

import x.y.z as foo

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

import x.y.z as foo

+

Andrey еще люди каке-то там тесты дурацкие пишут но вы их не слушайте

При всем этом экстеншены это одна из самых вкусных фич. Вторая конечно после конструкторов, но именно то чего очень сильно не хватает в джава. Не просто конечно экстеншенов, а экстеншенов и инлайна, ну и пропертей. Ой, опять котлин получился ;)

import x.y.z as foo

Спасибо тебе, добрый человек. Ты ответил на исходный вопрос, который и привёл к этому флуду.

При всем этом экстеншены это одна из самых вкусных фич. Вторая конечно после конструкторов, но именно то чего очень сильно не хватает в джава. Не просто конечно экстеншенов, а экстеншенов и инлайна, ну и пропертей. Ой, опять котлин получился ;)

.... а как же корутины..

Andrey еще люди каке-то там тесты дурацкие пишут но вы их не слушайте

А тесты тут вообще при чём? Понятно, что проблема отлавливаемая, вопрос был в том, как пофиксить на стороне того, кто пользует библиотеку экстеншенов.

о боже, я понял. Проблема архитектуры - это проблема архитектора а не яп.

Не согласен, что это проблема архитектуры. Экстеншены вводились для написания DSL в язык. 100% появятся библиотеки этих самых DSL на экстеншенах, а значит или их использовать и ловить потенциальные грабли, или свои велосипеды подо всё.

А тесты тут вообще при чём? Понятно, что проблема отлавливаемая, вопрос был в том, как пофиксить на стороне того, кто пользует библиотеку экстеншенов.

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

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

Замечательный вариант прокинуть костыль через другой ЯП ?

Мне кажется вы просто обсуждаете кейс, использования экстеншенов "не по назначению"

ERROR: S client not available

Не согласен, что это проблема архитектуры. Экстеншены вводились для написания DSL в язык. 100% появятся библиотеки этих самых DSL на экстеншенах, а значит или их использовать и ловить потенциальные грабли, или свои велосипеды подо всё.

тоже не согласен, сваливать все на яп не нужно

Замечательный вариант прокинуть костыль через другой ЯП ?

ну вариант же ?

По мне экстендить стоит классы данных

Чтобы добавить "сахарка" в свой dsl

Ну с точки зрения байт кода он и так static: public final static foo(LFoo;)Ljava/lang/String;

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

ну вариант же ?

Особенно поможет в Kotlin JS и Kotlin Native

Особенно поможет в Kotlin JS и Kotlin Native

там свои варянты найдутся

там свои варянты найдутся

В Native - палюбас. Через assembler вызывать ?

.... а как же корутины..

Определенно очень важная фича, но не в топе того что мне не хватает в джаве.

В Native - палюбас. Через assembler вызывать ?

О. Нам нужны ассемблерные вставки!

Чтобы добавить "сахарка" в свой dsl

А потом автор класса данных сыплет соль на сахар, решив, что это уже не совсем класс данных, и добавив в него перекрывающих мемберов

А потом автор класса данных сыплет соль на сахар, решив, что это уже не совсем класс данных, и добавив в него перекрывающих мемберов

кек, как данные могут стать не данными

Ссаными тряпками такого архитектора библитек надо гнать

ваще DTO — очень спорный паттерн

А при чем тут DTO

data != dto

ваще никак

кек, как данные могут стать не данными

Легко. Автор библиотеки с классами данных решил, что ничего плохого не будет, если в класс данных добавить мемберов. С точки зрения ООП ничего плохого и нет в расширении функциональности класса.

С точки зрения здравого смысла data class должны быть чистыми

С точки зрения здравого смысла data class должны быть чистыми

у каждого свой здравый смысл

Легко. Автор библиотеки с классами данных решил, что ничего плохого не будет, если в класс данных добавить мемберов. С точки зрения ООП ничего плохого и нет в расширении функциональности класса.

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

у каждого свой здравый смысл

вот с моей точки зрения data class не нужны, например

да не вдруг

С точки зрения здравого смысла data class должны быть чистыми

Что значит чистый? Неизменяемый? Без методов или как?

Ну взять и херить вещи пришедшие из функциональщины своим ООП - это такое

Что значит чистый? Неизменяемый? Без методов или как?

неизменяемый без методов

всё так

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

Обращать внимание на бренд? Лол, что за бред? Разве что проверить, не заведомо ли косячный бренд.

неизменяемый без методов

struct

а если его от Parcelable надо унаследовать

type class

а если его от Parcelable надо унаследовать

?