Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93006
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.181 as permitted sender)
To: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
References: <5723F2AE.2020806@garfieldtech.com>
 <f6a2370f-0468-6279-3981-82ed2eec4b90@gmail.com>
 <572529F2.9070606@garfieldtech.com>
Message-ID: <8e4ed849-f504-fe80-3c5f-e4ea114e99fa@gmail.com>
Date: Sat, 30 Apr 2016 15:14:47 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <572529F2.9070606@garfieldtech.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> <<MyAnnotation(foo = 'a', bar = 'b')>>

Here you have essentially created a named parameter syntax. That may be
a problem later, especially if we do implement named parameters and this
won't be the syntax we choose.

> $def instanceof MyAnnotation; //TRUE

That looks fine, however the problem is that if MyAnnotation is a class,
then PHP does not have multiple inheritance, so it's the only class it
can be. And given that your class has no methods, $def has no methods
either and can not have any semantics besides simple data object. Which
begs the questions: a) why it needs to be a class/object at all and b)
how would you support all those fancy AST things if you can't even call
methods on it. Of course, this is solvable by various way, but looks a
bit clunky conceptually. You expect classes to work in a certain way and
attributes to work in a slightly different way, at least with current
proposal.

> MyAnnotation can then have whatever other methods I feel like to
> access/mutate those values.  If that requires limiting MyAnnotation in

Mutable annotation is a very bad idea. That's BTW another problem of
defining it as class - we don't have real means to express immutable
value classes yet, not without some boilerplate. That's why interface is
better - it allows you to do immutability cleanly.

> That's essentially the same concept as I described above with the
> class.  Putting annotations on the object being created seems like a

Very similar, expect for:
1. Interface allows you to have richer semantics since you can implement
other interfaces and have other classes. Class pretty much limits you to
value object unless you do dirty tricks which essentially turn it into
interface. trait may be a bit in-between solution, but I didn't really
think about it yet, so there may be problems there.
2. You have no mutability issues.
3. You don't confuse template with actual data - i.e., with class, if I
just instantiate it, would it be a valid attribute? Of what?
4. You still can make complex attributes return ASTs.

> reasonable way to handle nested annotations at first glance, although it
> still doesn't resolve the main issue of Translatable which is that we
> scan the source code statically to find translatable strings.  (We look

That can be solved by making translatability a property of an attribute,
not a string. That looks to me a better design anyway - if you have a
button, what would it mean if its label sometimes translatable and
sometimes not? I'd expect translatability to be requirement of a context
- i.e. if we use string to display a button, it's translatable. Note
that it doesn't mean it *has* translations for every language - you
can't ensure that anyway - but it has the *option*. And if you make it a
property of the attribute itself, then your tool can have the list of
translatable attributes and then extract the values for these attributes
for translation.

That also makes more sense to me for translation - to translate
properly, you need to know the context of the string, same text can
translate differently depending on the context, so you'd want to know
what value you're translating.

-- 
Stas Malyshev
smalyshev@gmail.com