/*
 * Copyright 2003-2015 JetBrains s.r.o.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package jetbrains.mps.generator.runtime;

import jetbrains.mps.generator.runtime.NodeWeaveFacility.WeaveContext;
import jetbrains.mps.util.annotation.ToRemove;
import org.jetbrains.annotations.NotNull;
import org.jetbrains.mps.openapi.model.SNode;

import java.util.Collection;

/**
 * This is provisional interface to migrate from uses of {@link TemplateDeclarationWeavingAware} to
 * {@link TemplateDeclaration}. Denoted @ToRemove as this interface shall become integral part of <code>TemplateDeclaration</code> (if survives).
 *
 * IMPLEMENTATION NOTE:
 * For unknown reason, interpreted templates were not <code>TemplateDeclarationWeavingAware</code>, thus, a call from generated code to interpreted template
 * would fail with CCE in TEEI#weaveTemplate(). For that reason, I don't implement <code>TemplateDeclarationWeavingAware2</code> for interpreted templates, too.
 * I'd need to refactor generated templates and TEE first.
 *
 * DESIGN NOTE:
 * The only reason this interface is standalone, and not part of <code>TemplateDeclaration</code> right away is that I hope to drop TF.contextNodeQuery
 * and there would be no need to handle <code>weave()</code> in any different way than <code>apply()</code>. Functional approach is better for generator,
 * and TF.contextNodeQuery has only 2 uses throughout whole MPS. It might be reasonable to do it other way round and to support TF.contextNodeQuery
 * for any templates (not only under weaving). Anyway, template handling shall be identical for weave and apply cases.
 *
 * Provisional nature of the interface is the reason I left WeaveContext parameter here (although strived to get WC hidden, and only NWF exposed).
 * Since the method was exposed in few EAP builds, I'd need to introduce a new one, keep both for at least RC round, and then remove the one with
 * two arguments. As long as TF.contextNodeQuery is history, there would be no reason to have WC there (we use it to get original context node for
 * template fragment query context), and there's no need in this interface at all.
 *
 * @author Artem Tikhomirov
 * @since 3.3
 */
@ToRemove(version = 3.3)
public interface TemplateDeclarationWeavingAware2 {
  // @return in generated code seems to be capable of null return value
  Collection<SNode> weave(@NotNull WeaveContext context, @NotNull NodeWeaveFacility weaveFacility) throws GenerationException;
}
