On Sun, 12 Sep 2010 11:55:16 -0700, Stas Malyshev
<smalys...@sugarcrm.com> wrote:
> Hi!
>
>> 1. In Java annotations are a special type of an interface. But due the
>> lack of type hinting for scalar values we cannot use this construct,
>> because we cannot put some validation logic in an interface. My proposal
>
> I'm not sure I understand - what scalar type hints have to do with it?
> Anyway, annotation can't be interface since you'd have to instantiate
> it to get the values. Interface can't have values.
In Java I create an annotation as a special type of an interface.
@Target( { METHOD, FIELD, ANNOTATION_TYPE })
@Retention(RUNTIME)
@Constraint(validatedBy = CheckCaseValidator.class)
@Documented
public @interface CheckCase {
String message() default "{com.mycompany.constraints.checkcase}";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
CaseMode value();
}
I cannot say how this construct will be handled in the core but I think
an internal class will be automatically created which implements this
interface.
Due the strict typing in Java I cannot pass a string as value to the
annotation. An error will be caused.
If we had also type hinting or strict typing we could use the same
construct, because we must not check if a string and not an array was
given as annotation parameter. But since this is not the case we need a
construct similar to a class, so we can put the validation logic in it.
>
>> is to create a new "annotation" type. This type should have the same
>> rules as a class and should contain all features proposed in the
>> ReflectionAnnotation class. With this construct it should be possible to
>> use named or unnamed parameters for an annotation.
>
> I think this is very bad idea - to have language construct that is
> exactly like class but has different set of features. If named
> parameters are needed in PHP, let's add named parameters in PHP. But
> if we decide they are not needed in PHP, they shouldn't be in one
> particular corner of a particular syntax construct and nowhere else.
> This makes the language hard to learn and hard to understand - you
> never know what surprise the next syntax construct will bring you. I'm
> very strongly against only one construct in the language having named
> parameters syntax while other places don't.
>
>> 2. The syntax for arrays should be the same as in PHP. So we can use the
>> [] as annotation separator. When we allow expressions in the form
>> Annotation(array('value' => 4 %2)) or Annotation(array('value' =>
>> !MY_CONSTANT)) which I think is a valid construct, then we cannot use
>> the ! or % as annotation separator.
>
> Where this expression would be evaluated, in which context? Where
> would the variable values be stored? What happens if they change?
>
I don't know. That was a question on my part.
>> I think with this changes we have a separate language construct like
>> traits, which does allow a new syntax.
>
> Separate language construct doesn't mean separate rules. We are still
> in the same language, so we can't just randomly put arbitrary set of
> features together and call it a new construct. There should be some
> commonality between different language constructs within the same
> language.
That is not what I have said. I am of your opinion. The parameter list
of an annotation should have the same rules as the rest of the language
because it uses the same constructs. The only changes should be the
"annotation" construct which allows an instantiating other as a class
and named parameters as a part of the PHP core.
What is your idea to solve this problem? How would you create
annotations in PHP?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
