method promotion — lombok, кодогенерация, макросы редакторов и пр — это не pure language — оно конечно же «считается» но костыль. с подобными костылями можно даже на ассемблере писать :E
можно через наследование — но тогда будет diamond problem.
cложности с последующим кастованием — если реализовывать через свойства, то апкастить с костылями же приделся.
diamond problem — там по коду бага не существенная, но и с правильным конструктором для Х она не даст работать. по полям есть вот такой дело (хотя в данном случае это какбэ не поная реализация Б и Ц — методы для записи\чтения есть — но нет для чтения\записи).
по методам надо явно указывать от какого предка вызываешь.
class Fruit {
//...
public void Name() {
System.out.println("Fruit::Name");
}
}
class Apple {
private Fruit fruit = new Fruit();
//...
/* // Method promotion vvvvvvv
public void Name() {
fruit.Name();
}
*/
}
public class MyClass {
public static void main(String args[]) {
Apple apple = new Apple();
apple.Name(); // <---!!!!!!!!!!!
}
}
Method promotion ручками копипастить? Тоесть буквально на каждую композицию каждый метод?
Из практических будет diamond problem, отсутсвие method promotion, сложности с последующим кастованием. Они конечно решаемы, но это будут костыли похлеще копи-пасты изза отсутсвия генериков у го.
Если интерестно — можно тутже в треде попробовать. Если я ошибаюсь, буду реально рад
Не скажу за Windows. Но если на линуксе собирается, то проблем нет вообще.
Собрали под мониторингом, проанализировали, впихнули в сонар и наслаждайтесь.
У нас продукты наверное 4-5 компайлерами собираются — и все в один проход срабатывает.
А то что IronHead рассказывает — скорее всего силно криворукие люди были. В свое время мы даже splint под Code Composer Studio гоняли.
2015-12-23 10:12 — «Internal team reported that physical memory and CPU do not reflect Docker resource limits. This should be fixed in 9 and back ported to 8.»
Фиксы прибыли в январе 2017 :D
Да хоть капсом хоть прописью — GH не умеет объединять issues; пользователи вольны запускать в контейнерах всякое говно (по типу оракловской JVM), видят разные проблемы по разному и не могут отделить проблемы «своего» софта от проблем ядра или докера; в свежих процах тоже баги бывают, которые выглядат вообще адово (у самих на свежем железе с докером — хехе — черт знает что творилось пока дебиановский мэйллист не прочитали и микрокод не проадейтили).
можно через наследование — но тогда будет diamond problem.
cложности с последующим кастованием — если реализовывать через свойства, то апкастить с костылями же приделся.
diamond problem — там по коду бага не существенная, но и с правильным конструктором для Х она не даст работать. по полям есть вот такой дело (хотя в данном случае это какбэ не поная реализация Б и Ц — методы для записи\чтения есть — но нет для чтения\записи).
по методам надо явно указывать от какого предка вызываешь.
Method promotion ручками копипастить? Тоесть буквально на каждую композицию каждый метод?
Если интерестно — можно тутже в треде попробовать. Если я ошибаюсь, буду реально рад
А вы пробовали композицию реализовать на классах? Пусть даже с использованием наследования макросов и темплейтов
Былоб интересно знать, переползет ли корос на рпм, и что будет с тектоник и опеншифт
В вашей ссылке и есть gitflow
https://mobile.twitter.com/davecheney/status/938344651777499137
Про вред -er в именах объектов и то больше 101
А в чем стратегия?
будушее(стратегия);рассказатьСобрали под мониторингом, проанализировали, впихнули в сонар и наслаждайтесь.
У нас продукты наверное 4-5 компайлерами собираются — и все в один проход срабатывает.
А то что IronHead рассказывает — скорее всего силно криворукие люди были. В свое время мы даже splint под Code Composer Studio гоняли.
Фиксы прибыли в январе 2017 :D
Поэтому этот номер какбы вообще ниачем.