И вроде в Pyhton

тааак

И подозреваю что в JS

Метод класса (static) - он по логике своей реализует поведение не отдельного экземпляра, а класса объектов в целом.

interface Named { toName(): string; } class Vasya implements Named { toName() {return 'Vasya';} } ... function register(Named person) { registry.add(person.toName()); }

у васи надо метод сделать статическим?

если да,то как быть с функцией register()?

наверно фиговый пример с людьми

но не важно

пусть не люди будут, а что-нить другое

interface Named { toName(): string; } class Vasya implements Named { toName() {return 'Vasya';} } ... function register(Named person) { registry.add(person.toName()); }

Из этого кода явно следует, что разные экземпляры Named вообще говоря имеют разные имена (и из кода register явственно следует, что регистрируются не классы, а именно инстансы).

Из этого кода явно следует, что разные экземпляры Named вообще говоря имеют разные имена (и из кода register явственно следует, что регистрируются не классы, а именно инстансы).

ну да

Соответственно было бы очень странно делать метод static (который как раз говорил бы обратное)

это попадает в категорию "достаточная причина не делать статик"?

Соответственно было бы очень странно делать метод static (который как раз говорил бы обратное)

да, но ему ведь не нужен this

заменим toName() на toRace(), чтобы было ближе к сути

а registry пусть будет "перепись населения"

это попадает в категорию "достаточная причина не делать статик"?

Разные экземпляры вообще говоря имеют разные имена -> значит метод вообще говоря требует знать экземпляр/this и без этого не работает. Значит мы никак не можем сделать его static :(

Разные экземпляры вообще говоря имеют разные имена -> значит метод вообще говоря требует знать экземпляр/this и без этого не работает. Значит мы никак не можем сделать его static :(

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

а не только техническая независимость от this

Мммм можно ли сказать что вот это и было бы выражением семантики, "разные экземпляры вообще говоря..."?

ну да

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

?

и компилятор этой семантики не знает

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

ибо часть интерфейса

Угу, мне тоже так кажется. Ибо есть зависимость от состояния объекта (и this - как "физическое проявление" этой зависимости).

такой зависимости нет

т.е. из кода класса она не следует

А у тебя кроме Vasya есть ещё и Petya, Sasha и т.д.?

ну да

а есть еще Оля, у которй результат зависит от фазы луны

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

а есть еще Оля, у которй результат зависит от фазы луны

Вот это сейчас тонко было.

И у каждого Petya, Sasha та же песня - метод на _все_ экземпляры возвращает одно и то же (у всех скажем экземпляров Sasha вернёт "yo!"?)

с людьми неудачный пример

пусть будет getGender()

и классы каких-нить лягушек

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

оно не меняется

Меня в приведённом выше примере кода смущает в целом только вот что - ты вроде как регистрируешь _экземпляры_ класса, т.е. как будто они все могут давать разные результаты. Но из кода самого класса Vasya выглядит так, как будто разные результаты могут быть только у разных _классов_ (а не экземпляров). В этом месте вопрос - а почему тогда мы не регистрируем сами классы?

но является частью интерфейса

потому что оно не всегда зависит от класса (привет Оле)

:)

потому что оно не всегда зависит от класса (привет Оле)

Тогда как мне кажется "всё правильно сделал" - ну то есть "вообще говоря" зависимость от экземпляра таки существует, хотя в некоторых случаях (типа Васи, который не особо зависит от циклов Луны) эта зависимость вырожденная. Регистрируем экземпляры, метод принимает this (может неявно - зависит от языка).

ну например, у меня в проекте есть такая штука как именованные ссылки, они являются частью агрегата. в каких-то местах могут использоваться ссылки с определенными именами, в каких-то с произвольными. Поэтому есть интерфейс Link, а есть SelfLink implements Link, это ссылка с именем Self.

и допустим, в документе можно юзать только ссылки с именем self и related. Поэтому class SelfLink implements Link, DocumentLink

можно было бы делать if (link.name !=...) throw new Foo, но зачем нам if если есть полиморфизм

можно было бы делать if (link.name !=...) throw new Foo, но зачем нам if если есть полиморфизм

Ага, вот оно откуда всё идёт.

можно было бы делать if (link.name !=...) throw new Foo, но зачем нам if если есть полиморфизм

А можно ли как-то так: // положим есть список допустимых типов ссылок в данном документе ["а", "б", "х"] ... ... link.throwIfIncompatibleWith(["а", "б", "х"]); ... ...

Мягкий вариант: ... ... if (! link.compatibleWith(["а", "б", "х"]) throw BadLinkType(link); ... ...

А можно ли как-то так: // положим есть список допустимых типов ссылок в данном документе ["а", "б", "х"] ... ... link.throwIfIncompatibleWith(["а", "б", "х"]); ... ...

все равно if ;)

8 лет пишу без свитчей

вот и я решил поэкспериментировать

брат жив

минимизировать количество if

Просто экспекшены не нужны

все равно if ;)

Оооок, передавай лямбду :) ... ... link.executeWhenIncompatibleWith(["а", "б", "х"], ()->throw new BadLink()) ... ...

Лол

Оооок, передавай лямбду :) ... ... link.executeWhenIncompatibleWith(["а", "б", "х"], ()->throw new BadLink()) ... ...

там все равно где-то внутри if

да в любом. Когда их применение оправдано? Когда они - единственный способ?

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

Вот есть у меня метод, который не использует this. Есть ли хоть одна причина делать его статическим?

Есть. Ты сам её назвал

вот! зачем?

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

Нет, я конкретно именно о Java. Модификатор static в Java напрямую связан с классом, если поле статично, значит оно принадлежит классу, если метод статичный, аналогично — он принадлежит классу. Исходя из этого, можно обращаться к статическому методу или полю используя имя класса.

Вот что ты тут понаписал? В Java вообще нет свободных функций, итого мае можно было бы опустить, оставив только что метод или поле можно использовать без создания объекта

В php можно вообще всё делать, там полная свобода.

В рамках обсуждения ООП говорить о PHP даже как-то смешно... Ты бы ещё про bash рассказал...

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

Не должны, но наследуются, вот парадокс...

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

а зачем делать ее глобальной?

если мне нужна просто функция, я сделаю просто функцию

interface CallableByName { toName(): string; }

У тебя же это интерфейс, там не может быть по определению static методов, потому что интерфейс всегда вызывается через какой-то объект

У тебя же это интерфейс, там не может быть по определению static методов, потому что интерфейс всегда вызывается через какой-то объект

о том и речь

если мне нужна просто функция, я сделаю просто функцию

Делай

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

Это чисто технический варнинг, к дизайну это не относится

так зачем нужны статические методы? если не брать в расчет аргумент "в языке X статические методы это способ сделать Y, для которого нативное решение отсутствует в силу ограничения языка" (свободную функцию, именованный конструктор, итд)

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

Ты неправ в большинстве языков объект передается при вызове ЯВНО, указывается программистом в выражении вызова метода, он только в сам метод передается через неявный аргумент.

В рамках обсуждения ООП говорить о PHP даже как-то смешно... Ты бы ещё про bash рассказал...

А что так рассмешило?

так зачем нужны статические методы? если не брать в расчет аргумент "в языке X статические методы это способ сделать Y, для которого нативное решение отсутствует в силу ограничения языка" (свободную функцию, именованный конструктор, итд)

Ок давай пойдем от совсем простого... Что такое функция main ты знаешь? Как её оформлять без static?

А что так рассмешило?

Упоминание PHP

Ахах ?

Ок давай пойдем от совсем простого... Что такое функция main ты знаешь? Как её оформлять без static?

const main = (args: string[]):int = () => 0 как-то так, например

да как угодно

А что так рассмешило?

Я понял, ты мне сейчас будешь доказывать, что PHP -это язык программирования, и даже более того, что это ООП язык...

Я понял, ты мне сейчас будешь доказывать, что PHP -это язык программирования, и даже более того, что это ООП язык...

Нет конечно. Язык программирования - это то на чем программировать можно. А на пхп разве написано хоть что то?

const main = (args: string[]):int = () => 0 как-то так, например

Ну это ты лямбду написал, как я понимаю, это же свободная функция, не метод и не нестатический член класса, так?

Нет конечно. Язык программирования - это то на чем программировать можно. А на пхп разве написано хоть что то?

Вот именно!

Ну это ты лямбду написал, как я понимаю, это же свободная функция, не метод и не нестатический член класса, так?

так

ну она именованная уже, так что не лямбда

Нет, это сылка на неё именована, а не сама функция

предположим в языке есть просто функции. и функции высшего порядка. и неймспейсы и/или импорт/экспорт

блин, ну не важно

в контексте ооп - какая причина есть для существования статических методов?

так

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

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

Соответственно, вот это и есть причина существования статических методов

Соответственно, вот это и есть причина существования статических методов

Если тебе класс и метод не нужны, тебе даётся возможность их не использовать

Соответственно, вот это и есть причина существования статических методов

что "это"?

предположим в языке есть просто функции. и функции высшего порядка. и неймспейсы и/или импорт/экспорт

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

что "это"?

То, что тебе классы и методы не всегда нужны

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