Каково текущее состояние закрытий в Java?

Проблема

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

Для простоты, давайте предположим, что функцией перехода является linear (а не ease, которая является функцией синхронизации по умолчанию). В этом случае графики обеих шкал будут следующими: scaling functions

Поскольку мы хотим, чтобы конечная шкала внутреннего элемента оставалась постоянной, то (функция масштабирования) × (функция масштабирования) = 1 для всех временных аргументов. К сожалению, если мы сделаем умножение, в результате мы получим квадратную функцию (в нашем случае это -¾x² + 3x + ¾). Это удар по окончательному масштабированию, который вы можете увидеть в середине перехода. Чтобы избежать этого, вместо перехода к значению scale(n) нам нужно было бы масштабировать правило m в scale(1/m) css. К сожалению, мы не можем этого сделать, даже если мы использовали переменные css, поскольку они (пока) не допускают переходов (см. этот ответ)

Чтобы смягчить это, мы могли бы создать пользовательская функция синхронизации cubic-bezier, которая была бы обратной к квадратной функции, но я не смог сделать это вручную, и, вероятно, cubic-bezier не дал бы точную кривую для всех значений времени, особенно если бы мы хотели иметь основание функция синхронизации ничего, кроме linear.

Решение

Подход 1: Вместо масштабирования мы могли бы изменить размеры внешнего div, как показано ниже:

const outer = document.querySelector('.outer');

outer.addEventListener('click', () => {
  outer.classList.toggle('outer--active');
});
body { overflow: hidden; }

.outer {
  width: 100px;
  height: 100px;
  overflow: hidden;
  border-radius: 100%;
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  transform-origin: top left;
  transition: all 1s;
  cursor: pointer;
  border: 1px solid black;
}

.outer--active {
  width: 400px;
  height: 400px;
}

.inner {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  width: 400px;
  height: 400px;
  background: url('https://s3-us-west-2.amazonaws.com/s.cdpn.io/49240/14.jpg') center repeat;
  transform-origin: top left;
  transition: transform 1s;
}

Плюсы: сохраняет текущую структуру разметки html

Минусы: анимация прерывистая из-за ошибок браузера, связанных с сглаживанием субпиксельных переходов (например, Отчет об ошибках в Firefox )


Подход 2: Используйте обтравочную маску для эффекта круглого выреза, добавьте div для границы:

const outer = document.querySelector('.outer');

outer.addEventListener('click', () => {
  outer.classList.toggle('outer--active');
});
[ 114]

Плюсы: плавно масштабируется

Минусы: необходимо добавить еще один тег HTML для круглой границы / обода. Обод может иногда выглядеть отделенным от внутреннего образа.

19
задан trunkc 22 September 2008 в 19:14
поделиться

6 ответов

На Devoxx 2008 Марк Рейнхольд дал понять , что замыкания не будут включены в Java 7.


Подождите! Замыкания будут включены в Java 7. Марк Рейнхольд объявил об этом обращении на Devoxx 2009.


Будьте уверены! Замыкания ( лямбда-выражения ) были отложены до Java 8. Дополнительные сведения см. В Project Lambda (JSR 335) .

13
ответ дан 30 November 2019 в 02:56
поделиться

В настоящее время существует несколько конкурирующих предложений, BGGA, CICE, среди других. К сожалению, горячий спор остается по лучшему подходу. В результате маловероятно в этой точке, что закрытия превратят его в Java 7, из-за консервативной природы приемного процесса.

ключевая проблема здесь состоит в том, что может быть очень трудно добавить опции на существующий ранее язык, непреднамеренно не представляя значительную сложность. Это было опытом с Дженериками в Java 1.5, и многие обеспокоены, что он был бы составлен с введением закрытий.

Мой совет состоит в том, что, если Вы действительно хотите иметь доступ к функциям современного языка как закрытия, но хотят остаться в Java ecosysteym, необходимо смотреть на Scala.

7
ответ дан 30 November 2019 в 02:56
поделиться

Это неизвестно до Java SE, 7 JSR создаются (по-видимому, Danny Coward), и экспертная группа формируется, и содержание выбрано.

My Java 7 страниц являются хорошим набором ссылок о Java 7 в целом и имеют ссылки на все предложения по закрытиям и записи в блоге:

http://tech.puredanger.com/java7#closures

И я поддерживаю блог ссылки Java 7, где можно найти ссылки на закрытия и другой материал в:

http://java7.tumblr.com

И Вы могли бы найти мою Java 7 сообщениями в блоге Прогнозов, чтобы быть интересными также, если Вы хотите мои мнения: http://tech.puredanger.com/2008/08/02/java7-prediction-update/

ОБНОВЛЕНИЕ: Mark Reinhold заявил в Devoxx в декабре 08, что закрытия НЕ будут включены в Java 7 из-за отсутствия согласия по тому, как реализовать.

19
ответ дан 30 November 2019 в 02:56
поделиться

Groovy является лучшей альтернативой Java, я видел, что это включает функции динамических языков включая закрытия, расширение класса среды выполнения, и т.д. В то время как Ruby имеет небольшое преимущество дизайна, по моему скромному мнению, я должен был бы сказать, что то, что компиляции Groovy в байт-код Java и взаимодействуют с Java без ЛЮБОГО интерфейсного кода, является огромным плюс это, не может быть проигнорирован.

http://groovy.codehaus.org

3
ответ дан 30 November 2019 в 02:56
поделиться

По-видимому, Закрытия не будут в Java 7. См. это и это .

2
ответ дан 30 November 2019 в 02:56
поделиться

Замыкание не будет окончательно присутствовать в Java 7, но если вы ищете более легкое решение, чтобы иметь закрытие в java прямо сейчас, посмотрите, как они были реализованы в библиотеке lambdaj:

http://code.google.com/p/lambdaj/wiki/Closures

1
ответ дан 30 November 2019 в 02:56
поделиться
Другие вопросы по тегам:

Похожие вопросы: