Posted by fago on December 12, 2013 at 7:01pm
It folllows the log from todays d8 entity & field API irc meeting at #drupal-entity:
<amateescu> I suppose the elephant in the room is https://drupal.org/node/2114707
<Druplicon> https://drupal.org/node/2114707 => Allow per-bundle overrides of field definitions [#2114707] => 11 comments, 2 IRC mentions
<fago> oh dear!
;)
<amateescu> would be nice to have alex here..
--- timplunkettAFK heißt jetzt timplunkett
<fago> yeah, I'd suggest we try schedule a call where we have alex as well and discuss it then?
<amateescu> but feel free to start with something easier :P
<fago> and leave it out for today? ;)
yched, berdir ^^
<amateescu> I agree
<yched> works for me - IRC is not ideal for that one IMO
<berdir> ok with, only question there would be to split it up and in a first step, cache/store it by bundle so that we can use the instances, that would allow to clean up quite a few things and then we can add the override part without a lot of API changes?
<yched> berdir: good point
would definitely be good
<amateescu> maybe cache/store by bundle could be done as part of https://drupal.org/node/2002134 ?
<Druplicon> https://drupal.org/node/2002134 => Move TypedData metadata introspection out of the way [#2002134] => 9 comments, 1 IRC mention
<fago> berdir, sound good, if we are able to do that without running into the problem areas?
<berdir> fago: if not then we wait
<amateescu> it touches the same code anyway
<fago> amateescu, I think it would be easier to keep them separated
<yched> I've been vaguely wondering about a short way to force-put the instances in there, so that we can stop the dirty stuff everywhere else
<amateescu> okay
<berdir> just trying to unblock that part, specifically EntityDisplayBase::getFieldDefinition(), that thing is insanely slow
<fago> yched, berdir, yched yeah, so we need to fix the hook so we can have instances as well, then it should be fine for now + then re-iterate upon it later on?
<yched> berdir: yup
<yched> fago: yup (I guess)
<berdir> I can try to work on getting started there tonight, hopefully
<yched> but it means the hook needs to run by bundle
<amateescu> berdir++
<yched> berdir: would be insanely cool
berdir++
<fago> berdir, sounds great, else I can help as well :)
<amateescu> neeext :)
<fago> great, other topics we should discuss? I think we should go through the list of beta blockers / targets and discuss priority of stuff
<amateescu> fago: got some links at hand?
<fago> https://drupal.org/project/issues/search/drupal?status[]=1&status[]=13&status[]=8&status[]=14&status[]=4&version[]=8.x&issue_tags_op=all+of&issue_tags=beta+blocker%2C+Entity+Field+API
https://drupal.org/project/issues/search/drupal?status[]=1&status[]=13&status[]=8&status[]=14&status[]=4&version[]=8.x&issue_tags_op=all+of&issue_tags=beta+target%2C+Entity+Field+API
maybe let's start with the blockers - do the existing blockers make sense to you?
<amateescu> yep
the last one is really hard but I have a plan for it
<yched> menu links is above my head
<yched> fago: don't we miss a couple in there ?
<fago> yched, that are the one's that got "approved" so far
<berdir> yeah menu links is tough, it's complicated on it's own and there's so much going on around it with the hook_menu() changes and so on. So having a plan sounds good :)
<amateescu> here's my plan, from an email to the "performance team": https://privatepaste.com/10dcfd55f4
<berdir> btw, in the release management discussion just before this, it was discussed that each blocker/critical should have a person assigned to it that does not have to do it himself but is responsible
might be good to already do that now?
<fago> I've been staying out of menu links - now as we have multi-column fields is there anything blocking it left?
<amateescu> fago: berdir: it's all written there :)
<yched> amateescu: basically, needs more ad-hoc field types, right ?
<amateescu> yched: didn't parse that..
<fago> amateescu, how is internal url support for link field related to do the 5 column field?
amateescu, grouping the parent stuff together makes a lot of sense
amateescu++
<amateescu> fago: the 5 columns will be grouped together by using the 'link' field type
<yched> amateescu: I mean, the main blocker is to develop custom field types to group columns ? Did I get that right ?
<amateescu> for that, it needs internal url support :)
yched: yep
yched: 1) enhance the current link field
yched: 2) write the tree field
<fago> amateescu, yeah, so it would have to be its own field type anyway. but you want to extend it from the core link type, right?
<amateescu> fago: definitely
<fago> I see
hm, tree field in core ;)
<amateescu> fago: because shortcuts have the same need, a link field with internal url support
<yched> hm - tree field sound daunting...
<amateescu> a bit..
<berdir> yched: https://drupal.org/comment/8268561#comment-8268561, the thing is that we want a null storage that supports fieldable/content entities. We already discussed that FieldableFooStorageController should probably be called ContentFooStorageController, then the name would make much more sense
<fago> amateescu, totally yeah
<amateescu> so, back to the blocker list, menu links are "taken care of" :)
<fago> berdir, true. but would it still work if we do fieldable config entities? I guess so.
<amateescu> the render cache one is simple, just needs someone to look at it
unified repository is also crossing paths a bit with https://drupal.org/node/2002134
<Druplicon> https://drupal.org/node/2002134 => Move TypedData metadata introspection out of the way [#2002134] => 9 comments, 2 IRC mentions
<berdir> yep, should the typed data issue (or the two) be on that list as well?
<fago> amateescu, true.
<amateescu> berdir: I'd say so
alexpott amateescu
<amateescu> fago: if berdir took per bundle definitions, maybe you want to continue the metadata introspection one?
fago: the grunt work is there alredy :)
<fago> berdir, amateescu you mean those should block beta? I'm not sure - it shouldn't be a big api change, but more under-the hood changes. If you go with the same base classes you should be good to go + a few non-saying methods will leave
<berdir> fago: depends on whether we want to rename some of the generic methods. e.g. getValue() on lists
<fago> amateescu, sounds good to me. I can pick up from your definitions work and do the typed data issue first, then move on to the unified repository
<amateescu> fago++
<fago> berdir, if we want a better method, nothing stops us from just adding it right now?
<berdir> fago: true
<amateescu> thing is.. I have a lot of other issues waiting for me, like the menu links one..
<berdir> fago: anyway, if it's essentially blocking a beta blocker, then it's one too :)
<fago> berdir, I'm not sure it's block the unified repository - that should work without the other not?
<berdir> fago: just because you said "then move on to the unified repository", that kind of implied dependency to me :)
<fago> berdir, for the unified repository, I think the most important thing right now is to settle on the new public API. I can come up with a first proposal so we can start discussing
<berdir> ok
<fago> berdir, it's just the ordering on my todo list ;-)
yched, ^
<berdir> ok, are there other beta blockers that we're missing?
<yched> fago: yes, let's agree on an API
<yched> berdir: going through my list
There's the "remove old APIs" ones
https://drupal.org/node/2095195
<Druplicon> https://drupal.org/node/2095195 => Remove field_attach_form|view [#2095195] => 8 comments, 1 IRC mention
<yched> and http://drupal.org/node/2067079
<Druplicon> http://drupal.org/node/2067079 => Deprecate/remove the Field Language API [#2067079] => 18 comments, 1 IRC mention
<berdir> which has a number of related issues, there's also the preprocess, translable and so on, right?
is https://drupal.org/node/2018685 a duplicate of that one?
<Druplicon> https://drupal.org/node/2018685 => Decide what to do with field_is_translatable() [#2018685] => 21 comments, 1 IRC mention
<amateescu> I think those two are good candidates for beta blockers
<fago> yched, afaik removing deprecated functions doesn't have to happen before beta?
<berdir> assuming we have a replacement, for the field attach we afaik don't atm, right?
<yched> fago: not sure about that
<amateescu> don't we want beta to have the new APIs in the front row?
<fago> berdir, you use the entity controller instead?
<yched> so yeah, for field_attach() right now they are @deprecated but it's a lie
<fago> amateescu, sure, but if it's marked as deprecated already I personally I don't see a big issue when it gets removed later on
<yched> we have no actual replacement
<amateescu> something like "break contrib as much as possible before beta"
yeah, problem is it's not really deprecated, as yched points out :)
<berdir> https://drupal.org/node/2134887 is also related to those, I think
<Druplicon> https://drupal.org/node/2134887 => move field_view_field() / field_view_value() to methods [#2134887] => 12 comments, 1 IRC mention
<fago> yched, berdir: What sort of replacement would you need? You are not attaching anything anymore, you use the entity controllers. And for writing entity controllers, the default field logic should live in base classes?
<yched> this could work for EntityViewBuilder - because it's a real "helper logic object", so you can call it and call some logic
EntityFormController is more tricky, because it's a real entity form, not a helper object
<berdir> fago: there are at least two things that aren't properly supported by the form controller... single fields and multiple entities
<fago> yched, but yeah, field view has no replacement yet - so getting at least the public API + deprecation note in place should be imho a beta blocker.
<yched> you can't instanciate one just to call some method that happens to contain the logic you want
single-field edit form is also tricky - Edit.mosule currently calls field_attach_form(single_field mode)
<fago> yched, true, the only way to re-use it is to get a whole form and massage it afterwards
<yched> fago: right
<fago> berdir, yched oh, we've the issue about entity forms being not embeddable right now - that's probably rather critical given it should replace field_attach_form() ?
<berdir> yeah, that one
<yched> I got hit by that fact in http://drupal.org/node/2090509
<Druplicon> http://drupal.org/node/2090509 => optimize entity_get_render_display() for the case of "multiple entity view" [#2090509] => 21 comments, 1 IRC mention
<yched> entity_get_render_display() would be great to move to EntityViewBuilder, but entity_get_render_form_display() does not fit in EntityFormController
<berdir> also not sure what's up with the validation stuff. klausi doesn't seem to be working on it atm?
<fago> https://drupal.org/node/1728816
<Druplicon> https://drupal.org/node/1728816 => Ensure multiple entity forms can be embedded into one form [#1728816] => 10 comments, 1 IRC mention
<yched> because EntityFormController is not a good place to put "generic logic related to fields in forms", and we miss such a place
<fago> berdir, yeah, he hasn't been active recently. I think I'll meet him afterwards at the user group meeting so I'll check with him
<berdir> fago: ok
fago: there are like 3 criticals related to validation and two of them are large metas
<fago> yched, what kind of generic logic do you see needed here? Helper stuff for handling widgets etc?
<amateescu> yched: how about static methods?
<fago> berdir, do you have a link=
?
<yched> fago: attach widgets, fetch the right EntityFormDisplay...
<yched> amateescu: static methods, yeah... would feel out of place a bit, + you can't inject stuff in there
seems hackish to me
<fago> yched, hm, what's wrong with helper methods on the form controller?
yched, although I tentatively would put that more and more in the display ?
but the display lacks any notions of form submits etc. so that won't work out for form submits
<yched> fago: that's a possibility, but http://drupal.org/node/1875974 needs to happen first :-(
<Druplicon> http://drupal.org/node/1875974 => Abstract 'component type' specific code out of EntityDisplay [#1875974] => 44 comments, 7 IRC mentions
<amateescu> a factory for getting itself doesn't sound so bad
<berdir> fago: I think most issues are in the meta
<yched> basically, we have field_view_field() for "one off display of a field"
http://drupal.org/node/2134887 is moving those to EntityViewBuilder
<Druplicon> http://drupal.org/node/2134887 => move field_view_field() / field_view_value() to methods [#2134887] => 12 comments, 1 IRC mention
<yched> Edit.module needs similar functionality on the forms side
but putting them in EntityFormController is weird
<fago> yched, amateescu would it make sense to have a separate form operation for that? I mean it's just a different edit form, isn't it?
<yched> static methods that call \Drupal::xxx() ? and have a huge list of params for all the context that they cant get from the object (entity type, bundle, etc etc)
<amateescu> something like.. buildFieldForm() ?
<yched> fago: hm - not sure edit's "single field" form is really just a "regular enitty form filtered out to just one field", submit-wise
<amateescu> thing is I haven't really dug into the problems that yched ran into
<yched> amateescu: yes, with + methods for validate & submit too...
<amateescu> yched: and you would like to have those outside EntityFormController?
<yched> and in statics, you need to pull all context & dependencies just through the function signature
<fago> yched, not sure, why not ? so any violations that are specific to #access hidden fields will be automatically ignored, others that aren't specific to a certain field will continue to show up - would seems to fit for me, i.e. changed validation needs to stay
<yched> amateescu: in something more similar to EntityViewBuilder, yes... something that's not "a real entity form in itself"
<fago> amateescu, yched, looks like we've multiple issues around the display area. I guess we should come up with a proper attack plan, so we know which issues to focus on first?
<amateescu> yched: yeah, EntityFormBuilder :)
yched: and the current object could be called just EntityForm
<yched> fago: yeah, this is why I've been trying to focus on this "display area" lately
<fago> amateescu, yched Imho our form controller is the form builder plus handles validation and submit logic, as forms require more than just building.
<amateescu> fago: then EntityForm (the actual entity form) and EntityFormBuilder makes sense?
<amateescu> EntityForm is not needed on the display side because we don't have validation and submit there
that's how we can argue for this change
s/argue/propose/
<fago> amateescu, widgets need to act during validation/submit also, e.g. massage form values
<yched> yes, forms are more tricky that display :-)
<yched> fago: for me, http://drupal.org/node/2031725 and http://drupal.org/node/2144919 are first
<Druplicon> http://drupal.org/node/2031725 => Move all entity display interfaces to the core component [#2031725] => 89 comments, 1 IRC mention
http://drupal.org/node/2144919 => Allow widgets and formatters for base fields to be configured in Field UI [#2144919] => 41 comments, 2 IRC mentions
<yched> Then http://drupal.org/node/2134887 and http://drupal.org/node/2095195 are next on my todo
<Druplicon> http://drupal.org/node/2134887 => move field_view_field() / field_view_value() to methods [#2134887] => 12 comments, 2 IRC mentions
http://drupal.org/node/2095195 => Remove field_attach_form|view [#2095195] => 8 comments, 1 IRC mention
<amateescu> yched: if you fix the small nitpicks on https://drupal.org/node/2144919 , I can rtbc it today :)
<Druplicon> https://drupal.org/node/2144919 => Allow widgets and formatters for base fields to be configured in Field UI [#2144919] => 41 comments, 2 IRC mentions
<yched> amateescu: yes, I plan to finish that one after our call
<fago> yched, sounds good (and thanks for the rtbc)
yched, berdir, amateescu so should we use the sprint tag for high-lighting the issues we are currently focussing on again? i.e. sprint + entity field api?
<yched> and http://drupal.org/node/2090509 is also part of the equation - i.e where entity_get_render_(form)_display() end up
<Druplicon> http://drupal.org/node/2090509 => optimize entity_get_render_display() for the case of "multiple entity view" [#2090509] => 21 comments, 2 IRC mentions
<fago> so others now where to primarily help with reviews etc.
+k
<amateescu> fago: sounds good
<berdir> fago: k
<fago> yched, so what would be the primary api to get an entity display then? entity_load ?
<yched> http://drupal.org/node/2151775 is also related :-/
<Druplicon> http://drupal.org/node/2151775 => EntityFormController does things that only make sense for ContentEntities [#2151775] => 3 comments, 1 IRC mention
<amateescu> but not really blocking anything, no?
<fago> yched, yeah, I think we should have a ContentEntityForm base - I'd just prefer to avoid a separate interface if not really necessary.
<yched> fago: not sure... - see https://drupal.org/comment/8251955#comment-8251955
* fago figures he wanted to re-roll the other EFC cleanup issue
<yched> (was re "what would be the primary api to get an entity display then?")
amateescu: I dont think so, but might have non-minor perf impact - we load EntityFormDisplays for config entity forms...
<amateescu> lol
us++
actually, me--
as I wrote that :/
<yched> ContentEntityForm = API / base class change = beta blocker ?
oh no wait - we already have ContentEntityForm, just the code split is wrong
so, no API change, but just weirdness / perf impact
<fago> yched, responded there. yeah - that seams reasonable to me - a config entity form and a content entity form will have to use two different base classes - so those should be in place
<amateescu> yep, I just checked that we had ContentEntityForm
<-- alexpott hat (Quit: Leaving...) beendet
<yched> anyway - that's for the collection of form/display issues I'm currently neck deep in :-)
<fago> yched, amateescu: yes, so all fine for beta :)
<amateescu> I'd say so
<yched> yes
<amateescu> chx is annoying in https://drupal.org/node/2134967
<Druplicon> https://drupal.org/node/2134967 => FieldDefinitionInterface should include a getEntityType() [#2134967] => 22 comments, 1 IRC mention
<amateescu> fwiw :)
<fago> yched, maybe we should do an enttiy display section at https://drupal.org/node/2095603 ?
<Druplicon> https://drupal.org/node/2095603 => [meta] Complete Entity Field API [#2095603] => 65 comments, 12 IRC mentions
<fago> bikeshed!
<Druplicon> A metaphor for arguing endlessly over details of some small and relatively unimportant thing, taking up time that could be better spent on other things. See http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality and is also http://www.bikeshed.com/
<yched> fago: display/form ? they are really connected
fago: I'll do that
<fago> yched, hm. maybe form can stay for everything that's not display related?
yched++
<yched> fago: Yeah, i'll see how I can organize that
<yched> In other sections, there's the "when do we perform entity language fallback, exactly ?" issue, that I bump into more and more
berdir: ^ - rings a bell ?
<berdir> yeah
<yched> wish plach was there :-)
currently it's very unclear when you need to do ->getTranslation() yourself, or when it's done for you already upstream
<fago> yched, yeah, I think we should generally do that outside of the components/controllers and just work on the passed translation. but then we'd have to re-add the logic e.g. directly at the beginning of the route
<yched> so we sprinkle them in a lot of places
<fago> yched, and it's confusing that you can pass a $translation to the view builder but it would go with whatever $langcode is...
<yched> yes
<berdir> but not having $langcode doesn't work either
<yched> berdir: it doesn't ?
<berdir> we discussed that at length
no
<fago> why?
berdir, ^ ?
<berdir> well, it kind of would work if we just require that everyone calling those methods is responsible, but that's tricky and people would very likely not do it
then translations don't work
having an argument means we have a special NULL and know we need to use the default based on negotiation and stuff. not having it means people need to care everywhere where they view or even check access for an entity
there's a long discussion between me and plach in the issue that changed the entity translation stuff
https://drupal.org/node/2019055
<Druplicon> https://drupal.org/node/2019055 => Switch from field-level language fallback to entity-level language fallback [#2019055] => 220 comments, 21 IRC mentions
<berdir> see comment #125 and others above/below
basically, the probably is that we get the opposite of what we wanted. that everyone that loads an entity and does something with it needs to care and think about language and translation
probably = problem
<fago> berdir, I see :/
<yched> ouch
https://drupal.org/node/2019055 is long and closed - do we have another issue for that ?
<Druplicon> https://drupal.org/node/2019055 => Switch from field-level language fallback to entity-level language fallback [#2019055] => 220 comments, 22 IRC mentions
<berdir> we have two issues to remove $langcode from viewbuilder and access controller
but they don't really contain the discussion there
<yched> I though we had an issue about baking language negociation in the route upcasters ?
--> swentel (~swentel@98.188-247-81.adsl-dyn.isp.belgacom.be) hat #drupal-entity betreten
<-- swentel hat (Changing host) beendet
--> swentel (~swentel@drupal.org/user/107403/view) hat #drupal-entity betreten
<berdir> we discussed it, but I fear we don't have an issue
<fago> berdir, yched: maybe entity_load() should take an optional language argument + return the right translation by default?
<berdir> but that's beeing discussed in #145 in that issue
<fago> ok, so we need an issue which points out why it's a mess right now and shortly summarizes the problems & possible solutions
<berdir> yes.. #145 is a pretty good start there I think to start a new issue
<yched> seems so - berdir, could you open it ? :-)
<berdir> ok is there anything else you need to discuss? Otherwise I'm going to try and catch my bus/train to get home :)
<fago> berdir, thanks - I missing the details here :)
<berdir> actually, might already be too late for that
<fago> berdir, I'd have https://drupal.org/node/1976158#comment-8268879 on my list..
<Druplicon> https://drupal.org/node/1976158 => [meta] Rename entity storage/list/form/render "controllers" [#1976158] => 30 comments, 5 IRC mentions
<berdir> yes, I can create the issue
<fago> berdir++
<yched> berdir++
bus-- :-(
<fago> :/
I'm running late for our user group meeting also, anyway
<berdir> +1 on handler, I think that's the best we can come up with
<amateescu> there's always the next meeting to continue discussions
<fago> berdir, yched, amateescu: should we shortly discuss it and figure out services vs handler for us and then post a suggestion on the issue + timebox the discussion ?
<yched> +1 too - been +1 on that for months :-)
<berdir> looks like we're all +1 on handlers :)
<amateescu> fago: everyone is +1 on handler :)
<fago> that makes it easier :-)
<amateescu> hehe
<yched> WIN!!!!!
<fago> I think it has been mostly msonnabaum who was arguing for services
<berdir> amateescu: there's at least two issues about putting them in the dic
<amateescu> maybe the 4 of us > msonnabaum :P
<fago> hehe
<yched> DIC - blocking issues on pipe dreams IMO
<amateescu> lol
<fago> :D
sounds more like bip
<amateescu> similar enough
<berdir> deadlocking? :)
<yched> well, I meant in this specific case - don't see this happening
<fago> hehe. so should the language issue be blocking beta?
<berdir> me neither. writing that thing is already way too slow
<berdir> fago: probably at least as far as having a solution for the problem and knowing what to do
* amateescu doesn't have any opiniion on language stuff, I kinda stayed away from that..
<yched> agreed - coming to a clear policy for the outside world :-)
<fago> berdir, yeah, I think it should be clean in general in how people have to take care of language
amateescu, lucky guy :-)
<yched> run andrei, run!
<amateescu> fago: if you look at what else I have instead, NOT REALLY :)
<amateescu> speaking of which, https://drupal.org/node/2144327 should be a quick win and unblock plach's work on the storage stuff
<Druplicon> https://drupal.org/node/2144327 => Make all field types provide a schema() [#2144327] => 41 comments, 4 IRC mentions
<amateescu> berdir: null implementations are always fun to write :)
<berdir> amateescu: it's not completely null ;)
<yched> the last fuzzy thing in that patch was the mail field/property validation
berdir: you pointed to https://drupal.org/node/2023465
<Druplicon> https://drupal.org/node/2023465 => Allow validation constraints to add in message replacements [#2023465] => 2 comments, 2 IRC mentions
<amateescu> it's null enough (tm) :D
yched: berdir: I believe the agreement is too keep the second validation, no?
<berdir> I'm ok with that, it's not really introduced there, it would already happen right now if you use that field as a configurable one
<amateescu> *to
<yched> berdir: do you think that one should be bumped up a bit ? I'd field type providers are in a fuzzy situation about where to put their constraints without it ?
<berdir> possibly
<fago> amateescu, quickly reviewed it, looks mostly fine - see issue
<yched> So, bumping https://drupal.org/node/2023465 - but how do we bump exactly ? are we allowed to add beta-target ourselves ?
<Druplicon> https://drupal.org/node/2023465 => Allow validation constraints to add in message replacements [#2023465] => 2 comments, 3 IRC mentions
<amateescu> fago: phew, that's easy
<fago> yched, beta-targets are nothing official, only beta blockers are
at least that's what I thought ;)
amateescu, :)
yched, field types should provide additional constraints primarily on their field type definition
<berdir> fago: https://drupal.org/comment/8268545#comment-8268545 should be ready now :)
<fago> yched, unless they depend on the settings, hm - then it gets messy with the hack, true :/
<yched> fago: yeah, you can have constraints in the field definition, in the property definition, in the FieldItem::getConstraints()...
<yched> a bit fuzzy to me :-) and not all those places spit out error messages shaped the same way, so hard to unify UI reporting
<fago> yched, yes, so can we agree on doing logic in the definition objects? then we can start cleaning this up by moving type-defaults etc. there? https://drupal.org/node/2116341
<Druplicon> https://drupal.org/node/2116341 => Clarify how classed definition objects deal with defaults [#2116341] => 0 comments, 1 IRC mention
<fago> berdir, amateescu ^
I think we should be able to scratch the manager's constraint method by moving it into the definition ?
<amateescu> +1
<yched> fago: hmmm - how does my field type provided its "hardcoded" constraints then, if not in FieldItem::getConstraints() ?
<berdir> fago: @return static/self, hm, we have 120 self vs 20 static or so..
<berdir> timplunkett: ping
<timplunkett> berdir: pong
<amateescu> berdir: statics were all me :)
berdir: but we should generally convert all selfs
<berdir> timplunkett: ^
<yched> fago: constraints cannot be the only responsibility of the Entity::baseFieldDefinitions(), some / most of them are imposed by the field type ?
<fago> yched, I think we'd continue to do that, but make it static and invoke it from the definition + make the definition the primary place to ask for it ?
<berdir> amateescu: are you sure? @return static seems weird to me
<timplunkett> berdir: okay so
berdir: always use static:: in code
<amateescu> berdir: it works in phpstorm
<timplunkett> but for whatever reason, the convention for docblocks is @return self
<yched> fago: would need to think about it - is https://drupal.org/node/2116341 about it, or only tengantially related ?
<Druplicon> https://drupal.org/node/2116341 => Clarify how classed definition objects deal with defaults [#2116341] => 0 comments, 2 IRC mentions
<fago> yched, yes, totally related - I thought I had just pasted that. arg
oh I have :)
<berdir> ok, getting ready for bus earlier this time, will create that language issue and hopefully some patches tonight :)
<yched> will have to leave too
<fago> I'll leave as well.