Consider reading the Property Behaviors
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003148.html>
proposal, as attributes overlap with it. (Warning: loooooooong thread)
Félix
> Le 26 déc. 2015 à 13:57:04, JOSE MARIA GOMEZ CAMA via swift-evolution
> <swift-evolution@swift.org> a écrit :
>
> Dear all,
>
> Let me answer inlined.
>
>> El 26/12/2015, a las 19:15, Radosław Smogura via swift-evolution
>> <swift-evolution@swift.org> escribió:
>>
>> Hi Dimitir,
>>
>> Thanks for your questions, as you pointed me to deeper considerations and
>> better description of idea.
>>
>>> On 26 Dec 2015, at 16:20, Dmitri Gribenko <griboz...@gmail.com> wrote:
>>>
>>> On Sat, Dec 26, 2015 at 3:59 PM, Radosław Smogura <rsmog...@icloud.com>
>>> wrote:
>>>> So,
>>>>
>>>> What do you think about syntax like this:
>>>>
>>>> // Declaration
>>>> @AttributeUsage(RUNTIME) //Can be SOURCE - attribute not emitted into
>>>> binary
>>>> @AttributeTarget(PROPERTY) //Other CLASS, ENUM, METHOD, INIT
>>>> @attribute JSONProperty {
>>>> var name:String!;
>>>> var serializable:Bool? = true;
>>>> var deserializable:Bool? = true;
>>>> }
>>>
>>> Is this a new declaration kind? Do you think we could make it work
>>> with existing language constructs instead, like structs? Any
>>> downsides to that?
>> It’s really good concern and I have to describe attribute concept in more
>> details. The _implementation_ of attributes would and should use existing
>> constructs like structs or classes - I prefer classes as it will allow
>> attributes to subclass some common class (Attribute?), so in future new
>> functionality can be added.
>>
>> Let’s consider attributes, and marking struct with @Attrbute.
>>
>> On runtime attributes will be passed as references or value objects (just to
>> keep contract programming) and assignment to attribute properties should be
>> prohibited:
>> - if attribute is bound to type, than attribute would be nothing more than
>> extension of static context of that type,
>> - it’s error prone for developers, as someone could change i.e. JSON
>> property name.
>>
>> Attributes are metadata, and do not require methods (however methods could
>> be interesting and innovative addition). So attribute’s properties should be
>> declared with let, instead of var, to prevent modification of those, but
>> from other hand we would like to set default values for some properties, I
>> just think that declaration like this would be confusing:
>> @Attribute
>> struct JSONProperty {
>> /* … */
>> let deserializable:Bool? = true;
>> }
>>
>> Additionally having attributes as a new construct will give us more
>> flexibility on changing syntax and adding new features in future.
>>
>> I think this implies that attribute can’t be considered as struct (on
>> language level), and should be treated as new language construct.
>
> I do not agree that attributes should only provide metadata. I think they
> shall also provide means, like in Java or Python, to modify the behavior in
> runtime. For this, mirroring would be needed.
>
>>>> // Usage
>>>> @JSONProperty(name=“id”)
>>>> var id:Int;
>>>>
>>>>
>>>> Attributes should be module aware (actual attributes should be redefined
>>>> as Swift attribute, for beginning still can be hardcoded).
>>>
>>> Sorry, I'm not sure what this means.
>> Attributes should be in module. So modules can define attributes with same
>> name. Right now attributes are global.
>>>
>>>> The attribute’s name have to be unique in module. It’s compile time error
>>>> if attribute, class, enum, struct, etc has same name.
>>>>
>>>> Attribute’s properties are read only and can’t be assigned - so during
>>>> reflection no-one would change ‘shared’ values.
>>>
>>> I think using structs and requiring that attributes are value types
>>> would solve both issues.
>> I think attributes should be treated as new language construct, regardless
>> how those will be implemented on runtime - it can be struct or class.
>
> I do not see why it should be a new construct, in Java it is, but in case of
> Python it is not. Another option would be to define the attribute @attribute
> that would identify a class or a struct as an attribute.
>
>>>> Attribute’s properties can only support basic types: primitives, strings,
>>>> types, and other attributes (optional).
>>>
>>> Well, there is no such thing as "basic types" in Swift. Strings,
>>> integers etc. are defined in the standard library and the compiler
>>> does not know anything special about them.
>> By basic type I meant a types which can be serialised to format which will
>> not change in future. Numbers, strings, type names, arrays of those can be
>> stored in binaries without risks of backward incompatibility, objects and
>> structs are more fragile. I think next answer will clarify more.
>
> I think this is always the case when you have a compiled language, you always
> store information as a binary when you have a library.
>
>>>> When declaring attributes, properties can be set to constant values
>>>> (static let) or enum values, however the final value is stored in binary,
>>>> not a reference to it.
>>>
>>> Again, given that strings are defined in the standard library, and
>>> that the language does not have a notion of a constant expression, I'm
>>> not sure how this would work. I'm not saying it can't, I'm just
>>> saying you need to introduce a lot of new language concepts and
>>> compiler machinery.
>> It’s another good question. By const I mean virtual concept of static let
>> declaration. My motivation is to keep attributes as static metadata.
>>
>> Let’s consider three levels of attributes:
>> - source - those attributes are present only in source file and are not put
>> in binary, such attributes can be used to mark pieces of code for external
>> tools like visual UI designers, UMLs, etc
>> - compile - those attributes are present in output binary, but have not
>> meaning on runtime - ie. @Deprecated,
>> - runtime - those attributes are present on runtime, and can be inspected by
>> libraries to affect execution, ie.: @JSONProperty, @NSManaged
>>
>> My other concern is related to attribute storage (let’s skip implementation
>> of this). Suppose you want to centralise some values, ie. messages with
>> following pice of code
>> CommonMessages {
>> static var genericError = “Something went wrong :(“
>> }
>>
>> And you want to bound a property to message when validation fails.
>> @ValidationMessage(message=CommonMessages.genericError)
>> var id:Int;
>>
>> - For runtime referencing variables can be confusing, as some one seeing
>> above notion can think that changing genericError will change message on
>> runtime (annotations are static, so it will not work),
>> - For compilation level attributes compiler has limited possibilities to
>> evaluate what genericMessage is, as there is no application runtime (it will
>> be compiled), so only simple traversals through source can be performed.
>> Even for const it can be hard right now.
>>
>> The other question arises here, suppose CommonMessages are in external
>> library,. What should happen if it changes, should a genericError be
>> referenced or it’s value copied and stored in binary? Referencing could be
>> quite interesting topic.
>>
>> We can consider allowing simple or more complicated expressions in attribute
>> properties
>> @Size(width=20+50+sqrt(12))
>> As long as those refer static context.
>>
>>>> The compiler has build in support for core attributes, which can affect
>>>> code generation. Compiler may perform additional checks on core attributes.
>>>
>>> OK.
>>>
>>> Another question is, how would you inspect attributes at runtime?
>> I would like to focus on syntax, semantic and parsing. This will require
>> answering question how to store attributes (and I would like to move this to
>> separate chain, as it will be long discussion). From the other hand, some
>> questions still should be answered, ie.
>>
>> How attribute should behave in such a case:
>> @ValidationMessage(message=CommonMessages.genericError)
>> var id:Int;
>>
>> Should genericValue be copied or referenced (see above consideration), this
>> implies what and how to store.
>
> Probably, in this case it would be good to have a look on Java annotations.
> This can provide some hints on how to store the compiled information.
>
>>> Dmitri
>>>
>>> --
>>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <griboz...@gmail.com
>>> <mailto:griboz...@gmail.com>>*/
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
>
> Aquest correu electrònic i els annexos poden contenir informació confidencial
> o protegida legalment i està adreçat exclusivament a la persona o entitat
> destinatària. Si no sou el destinatari final o la persona encarregada de
> rebre’l, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo,
> distribuir-lo, copiar-lo ni a revelar-ne el contingut. Si heu rebut aquest
> correu electrònic per error, us preguem que n’informeu al remitent i que
> elimineu del sistema el missatge i el material annex que pugui contenir.
> Gràcies per la vostra col·laboració.
>
> Este correo electrónico y sus anexos pueden contener información confidencial
> o legalmente protegida y está exclusivamente dirigido a la persona o entidad
> destinataria. Si usted no es el destinatario final o la persona encargada de
> recibirlo, no está autorizado a leerlo, retenerlo, modificarlo, distribuirlo,
> copiarlo ni a revelar su contenido. Si ha recibido este mensaje electrónico
> por error, le rogamos que informe al remitente y elimine del sistema el
> mensaje y el material anexo que pueda contener. Gracias por su colaboración.
>
> This email message and any documents attached to it may contain confidential
> or legally protected material and are intended solely for the use of the
> individual or organization to whom they are addressed. We remind you that if
> you are not the intended recipient of this email message or the person
> responsible for processing it, then you are not authorized to read, save,
> modify, send, copy or disclose any of its contents. If you have received this
> email message by mistake, we kindly ask you to inform the sender of this and
> to eliminate both the message and any attachments it carries from your
> account. Thank you for your collaboration.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
