Hi to all.

Mmmm... this is a quite controversial proposal!!!

Nice to be able to discuss about this so disruptive implementation :-))

In my opinion, this can lead to quite misinterpretations. The usual 
expectations for anybody coming into Isis (or migrating his current JDO - JPA 
in the near future - into Isis) there would be for all properties with both 
getter and setter to be writable.

If we analize our entities, nearly all properties have getters and setters. 
This proposal would force us to create modifyXXX and clearXXX methods for all 
them, invalidating the model.

Perhaps this more restrictive model could be optional, but my opinion would be 
to keep it as writeable by default (as it's assumed by nearly all other 
platforms or frameworks).

Just my 2 cents...

Also, to implement modifyXXX and clearXX would not imply that tests are 
available for all them, so the responsibility to properly testing them would 
not be delegated to the platform. So the programmer would not avoid to write to 
all tests.

Sorry for not agreeing (by now ..) :-))



El 13/06/2014, a las 08:41, Dan Haywood (JIRA) <[email protected]> escribió:

> Dan Haywood created ISIS-804:
> --------------------------------
> 
>             Summary: Make (entity) properties read-only by default.
>                 Key: ISIS-804
>                 URL: https://issues.apache.org/jira/browse/ISIS-804
>             Project: Isis
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: core-1.5.0
>            Reporter: Dan Haywood
>            Assignee: Dan Haywood
>             Fix For: core-1.6.0
> 
> 
> Currently properties are read/write by default; the programmer has to 
> annotate with @Disabled (or equivalent) to make read-only.
> 
> While this "subtractive programming" approach is nice for demo's, the truth 
> is that with larger applications, if not rigorously and completely tested, 
> the end-user may get the opportunity to change something that they ought not; 
> potentially corrupting data.
> 
> It would be better (and safer) for properties to be read-only by default.
> 
> The presence of the modifyXxx(...)/clearXxx() supporting methods would then 
> indicate that they are read-write.
> 
> Another possible benefit is that - if we implement ISIS-273 (to read from 
> fields) then the amount of boilerplate would substantially be reduced if a 
> tool like Lombok was used.  That is, read-only properties would consist 
> solely of a private field; read-write properties would be the field plus the 
> modify/clear.
> 
> It might also make sense for the clearXxx() method to be optional; that is, 
> to allow modifyXxx(..) to be called with null.
> 
> NB: for view models, properties could (perhaps) remain as read-write; there 
> are no side-effects.
> 
> This change requires discussion on the mailing list.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.2#6252)


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.





Reply via email to