rfc:compact-object-property-assignment

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
rfc:compact-object-property-assignment [2020/03/18 02:17] – jgivonirfc:compact-object-property-assignment [2020/03/22 03:17] – jgivoni
Line 3: Line 3:
 **COPA: A //pragmatic// approach to object literals** **COPA: A //pragmatic// approach to object literals**
  
-  * Version: 1.2+  * Version: 1.3
   * Date: 2020-03-17   * Date: 2020-03-17
   * Author: Jakob Givoni <jakob@givoni.dk>   * Author: Jakob Givoni <jakob@givoni.dk>
-  * Status: Under Discussion +  * Status: Under [[https://externals.io/message/109055|Discussion]]
-  * Discussion: https:%%//%%externals.io/message/109055+
  
 ===== Introduction ===== ===== Introduction =====
Line 19: Line 18:
 As an alternative to writing a data structure as an associative array, COPA gives the data a **//documented signature//** so that you know what parameters are expected and their values. As an alternative to writing a data structure as an associative array, COPA gives the data a **//documented signature//** so that you know what parameters are expected and their values.
  
-You may find that COPA is best suited when you don’t mind public properties you don’t require a constructor, since as [[https://wiki.php.net/rfc/write_once_properties#read-only_semantics|the saying goes]]: //Object construction is a fuzzy concept in PHP and lazy initialisation is a feature!//+You may find that COPA is best suited when you don’t mind public properties, don’t require a constructor and is willing to compromise on magic enforcement of mandatory properties, since as [[https://wiki.php.net/rfc/write_once_properties#read-only_semantics|the saying goes]]: //Object construction is a fuzzy concept in PHP and lazy initialisation is a feature!//
  
 ==== Example ==== ==== Example ====
Line 45: Line 44:
 ]); ]);
 </code> </code>
 +COPA is everything that comes after the object expression. You can use COPA on any expression that evaluates to an object. COPA is not tied to object construction, but can be used anytime, anywhere in the objects life, as many times as you want.
 +
 //See more use cases below - and keep an open mind about the syntax; the options are limited these days :-)// //See more use cases below - and keep an open mind about the syntax; the options are limited these days :-)//
  
Line 370: Line 371:
 ==== Alternative syntaxes ==== ==== Alternative syntaxes ====
  
-Some alternative syntaxes for COPA has been suggested, but I’m not convinced they can be implemented without hassle:+I’m going to suggest some alternative syntaxes, that we can vote on, provided their feasibility has been vetted by an experienced internals developer: 
 + 
 +=== Syntax A === 
 + 
 +This is the originally proposed one:
  
 <code php> <code php>
-$foo = new Foo()[ +$foo->[ 
-   property1 = "hello", +    a = 1, 
-   property2 = 5, +    b = 2, 
- ];+    c = (new Foo)->[ 
 +        a = 3, 
 +        b = 4, 
 +    ], 
 +];
 </code> </code>
-For some reason it’s not possible to do this:+=== Syntax B === 
 + 
 +Since the [[https://wiki.php.net/rfc/deprecate_curly_braces_array_access|deprecation of curly brackets as array access in PHP 7.4]], that notation could be used to assign properties:
  
 <code php> <code php>
-new Foo()->doSomething(); // syntax error, unexpected '->'+$foo{ 
 +    a = 1, 
 +    b = 2, 
 +    c = (new Foo){ 
 +        a = 3, 
 +        b = 4, 
 +    }, 
 +};
 </code> </code>
-It’s necessary to wrap the instantiation in brackets:+=== Syntax C === 
 + 
 +No wrapper:
  
 <code php> <code php>
-(new Foo)->doSomething(); // Ok+$foo-> 
 +    a = 1, 
 +    b = 2, 
 +    c = (new Foo)-> 
 +        a = 3, 
 +        b = 4, 
 +    ;, 
 +;
 </code> </code>
-Which is why I think it will be necessary in my proposal as well.+Nesting becomes awkward - how do we jump out again?
  
-Furthermore, a variable or object directly followed by square brackets usually imply array access on it. That syntax would conflict with COPA.+=== Syntax D ===
  
 +Repeating the array for familiarity:
  
-----+<code php> 
 +$foo 
 +    ->a = 1, 
 +    ->b = 2, 
 +    ->c = (new Foo) 
 +        ->a = 3, 
 +        ->b = 4, 
 +    ;, 
 +; 
 +</code> 
 +Same issue with nested as previous. We need to find a way to express end of COPA block.
  
-//Unless someone can convince me that it’s trivial to implement another syntax that looks even better, my stance is that the people who are going to vote no on this because they don’t find the feature useful are not gonna change their mind if the syntax changes, and the people who find this feature useful will prefer rapid adaptation over solving implementation issues.//+=== Syntax E ===
  
 +Like the original but with normal brackets instead of square ones:
 +
 +<code php>
 +$foo->(
 +    a = 1,
 +    b = 2,
 +    c = (new Foo)->(
 +        a = 3,
 +        b = 4,
 +    ),
 +);
 +</code>
 ==== Mandatory properties ==== ==== Mandatory properties ====
 +
 +Some criticism has been that COPA is of little use without also enforcing mandatory properties to be set.
  
 Rowan Tommins: Rowan Tommins:
Line 403: Line 455:
 > It seems pretty rare that an object would have no mandatory properties, so saying “if you have a mandatory property, COPA is not for you” is ruling out a lot of uses. > It seems pretty rare that an object would have no mandatory properties, so saying “if you have a mandatory property, COPA is not for you” is ruling out a lot of uses.
  
-Is it possible to amend the proposal to help with mandatory properties? Or at least give an example of how you would add the check yourself?+Michał Brzuchalski: 
 + 
 +> This helps to avoid bugs where a property is added to the class but forgot to be assigned it a value in all cases where the class is instantiated and initialized 
 + 
 +Mandatory properties are typed properties without a default value. They are in the uninitialized state until they are assigned a value. It has been suggested that an exception should be thrown at the end of the constructor if any property is still uninitialized, but this idea has not yet caught on. COPA doesn’t have any obvious way of enforcing mandatory properties. 
 + 
 +For now you must continue to write your own validation code to be carried out at the appropriate “point of no return”. 
 + 
 +==== Atomic operations ==== 
 + 
 +It’s also been suggested that assigning multiple values using COPA should be an atomic operation that either succeeds or fails in its entirety. 
 + 
 +That does sound cool as well, and may seem like the expected behavior for some. 
 + 
 +Still, I’m not convinved it’s worth the extra hassle, since what were you planning to do with the incomplete object anyway? 
 + 
 +Chaining method calls are not an atomic operation and if an exception is thrown in the middle I doubt you would raise an eyebrow about the previous call having altered the state of the object.
  
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
Line 416: Line 484:
   - I don’t find the feature useful   - I don’t find the feature useful
   - I don’t like the syntax   - I don’t like the syntax
-  - A more comprehensive solution to this problem will be better +  - I prefer a more comprehensive solution to this problem 
-  - A thinner solution to this problem will be better +  - I prefer a narrower solution to this problem 
-  - This breaks backwards compatibility too much+  - This breaks backwards compatibility
   - This will negatively limit future changes   - This will negatively limit future changes
-  - It will be a nightmare to implement and maintain+  - This will be a nightmare to implement and maintain
   - I prefer not to say   - I prefer not to say
  
rfc/compact-object-property-assignment.txt · Last modified: 2020/04/14 06:30 by jgivoni

Page Tools