|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #81203 [ FEATURE ] StructType like interface for arrays
Submitted: 2021-06-27 14:08 UTC Modified: 2021-06-28 12:03 UTC
From: 6562680 at gmail dot com Assigned:
Status: Wont fix Package: *General Issues
PHP Version: Irrelevant OS: Win10
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: 6562680 at gmail dot com
New email:
PHP Version: OS:

Further comment on this bug is unnecessary.


 [2021-06-27 14:08 UTC] 6562680 at gmail dot com
Every project every day we implement Serializer to convert incoming JSON data into nested object tree with validate the data.

Main idea is about spliting your project into modules.

I give an example:

You have two modules - Auth and Company
Auth module needs something like User or Identity or User interface
But the Users by the task is depend from... maybe Agency or business network.

So you need User class inside Company module
Also you need User class inside Auth module (or some of its representation)

Once you extend Company's User you create Hard link that should be resolved with maybe Interfaces. But your Auth User class still not implement Interface from Company class, so even if you create interface - you still need to create class that extend or realise original one.

Everywhere that problem is solved using maybe Doctrine - there is a Entities (with damn annotations, relations and so on, required only for DAL layer) - and now you project is working only if you have DAL layer with all Entities.

You cannot build small module with ValueObjects + Interfaces - because DAL layer needs then you interfaces implemented on Doctrine entities.

But Doctine entities forbid to set `id` attribute and also have additional Event handlers like prePersist/postPersist, constructors, cloners and stuff that is required ONLY in DAL layer.

So every application becomes a monolith, linked, related and coupled.

Somebody decides to use Microservices then. They write own Message Bus... same like base PHP stack trace.

Somebody decides to implement EventDispatcher and then everyday tries to build event call tree to control what exactly was first, second... etc.

Main problem here is YOU CANNOT JUST VALIDATE objects or arrays in 2-3 lines of code.

Serializer solves it like walk recursive and json and then maps incoming array into your entities/requests/valueObjects, then we need annotations to validate, and then - if some task expects little different data from global one - you need to implement almost layer to do that.

How about implement global type (like interface) named Struct (YourObjectStruct) and create validator that can:
1. validate array
2. return errors in nested array
3. return array or map array to structs like serializer does

class UserStruct
  public $prop1;
  public $prop2;
  public $prop3;

  public static authorize() : array { return []; }
  public static required() : array { return []; }
  public static rules() : array { return []; }

class UserRequestStruct extends UserStruct
  public static authorize() : array { return []; }

that structs could be controlled with next service:

interface StructerInterface
  // returns bool
  public function fails(value, rules, messages, labels) : ?ValidationInterface;

  // returns validation if failed
  public function verify(value, rules, messages, labels) : ?ValidationInterface;

  // returns validation if succeeded
  // throws exception on fail
  public function validate(value, rules, messages, labels) : ValidationInterface;

  // returns errors array (you can pass existing validation to extract errors from)
  public function errors(valueOrValidation, rules, messages, labels) : ?ValidationInterface;

  // returns tree of struct object
  // throws exception on validation failed
  public function unserialize(value, rules, messages, labels) : object;

Main thing of the concept - create local interfaces to check incoming object with properties.

You can pass your object without any interfaces, object would be converted to array, validated and then used like "match our local interface"

It works on frontend for example typescript.

There isnt "data interface", ts just inspects on IDE (that is dangerous, but allows to use StdObject without creating Domain class, you just sure you pass that data like interface

So you can use your arrays or convert it into object tree, and you need interfaces only for services instead everywhere everysecond.

Thank you.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2021-06-27 20:57 UTC]
-Status: Open +Status: Wont fix
 [2021-06-27 20:57 UTC]
I can't tell what this "struct" thing is supposed to be, but the bulk of what you wrote (as far as I could understand it) pertains to validation. Data validation is not a job that should be performed by the PHP language itself, and there are plenty of frameworks and libraries and design patterns that can handle the job.
 [2021-06-27 22:18 UTC] 6562680 at gmail dot com
Main thing of this request is ask you guys to implement type that allows match some object without creating class and implementing interface.

Interface segregation is about SERVICE layer, datalayer always has a problem with damn extend/composite.

Correct library should have enough objects to be published, but almost all the projects needs to be written faster.

Language should give options to write faster.

Generics allows to skip code generation - i need to write code generator every project to just generate damn entities by database for doctrine/eloquent + repositories + so on stuff cause of you, guys can't just create syntax like:

$repo = $entityManager->getRepo<EntityClass>(EntityClass);

i always need to create some phpdoc stuff /** @var EntityClass $repo */ or even create adapter class.

Class nesting allows to reduce size of dependency injection layer - declined long time ago, currently i need to create factory with public methods everywhere

Readonly props reduces count of public setters - there is no thing

Structs allows to use global objects without mappers and without creating tonns of classes. It works like your typehinting where you define "string" - it maps any type to your and check it is possible (Interfaces cannot do that! It is required on DAL layer every second!!!)

Decorators allows to configure dependency injector directly in your class and also allows to configure even router BEFORE call the method and allows to collect it by class reflection. - Currently we install Doctrine AnnotationReader (if you see how its realised - you prefer the death) - everytime...

You have to ignore requests to create arrow syntax to launch functions and think about how make language EASIER TO WRITE, not MORE FEATURED.

As i see your main idea - give community opportunity to solve anything as they want - creates anti-patterns, pseudo-patterns, "experts" and "bloggers" - but really we wont to create CRM in several people - we need damn team cause of tonns of symbols we need to print in IDE.

Thank you.
 [2021-06-27 22:40 UTC] rtrtrtrtrt at dfdfdfdf dot dfd
your problem is that you confuse programming language with framework
 [2021-06-28 00:23 UTC] 6562680 at gmail dot com
No, i suppose my problem is realistic position, where the education is almost down and war is incoming, and i try to solve task alone with 2 guys, because new ones becomes more stupid that few years ago.

50% agried of php, 30% beginners, 15% strong juniors, 4% married middles who wont work 1hour over, 1% senior that can handle own blog but still cant help, and noone can explain why he's doing that way.

and i see it that last 10 years. "My problem is-guy"

Nobody from community ask me to learn or something. Everybody goes conferences to be the star. Nobody wants to code, everybody wants to hype.

World is dying, you cant still "ask the community", you have no community for now.
 [2021-06-28 05:50 UTC] rtrtrtrtrt at dfdfdfdf dot dfd
well, you sound like ab eginner, otherwise you would have framework solutions written in the past years and not start always from scratch or use existing frameworks

anyways, PHP is a PROGRAMMING LANGUAGE and not a framework
 [2021-06-28 08:52 UTC] 6562680 at gmail dot com
I understand that - php is a language.
Language with
- no generics
- no readonly props
- no class nesting
- no decorators
- no dependency injector
- no structs
- no, but ok - no serializer/validator inside

It seems to really STANDARD things in 2021. Like patterns.

In this PROGRAMMING LANGUAGE user MUST ignore readonly and create public methods, because PHP devs likes to speak instead of getting answer in the mind at mondays meetup.

Its just an example, and today when i understand how this things required - am sure it should be language things, no framework can change class nesting behavior or property readability - we need \ReflectionClass everywhere cause of "this is a language"

And ignore languge and use another cause of "its language".
Ok, community could just ignore it, and we have no concurrency now... and NO DAMN HELP.
 [2021-06-28 12:03 UTC]
-Block user comment: No +Block user comment: Yes
 [2021-06-28 12:03 UTC]
Locking before Harald shows up again.

Generics and read-only properties are reasonable and have, at one time or another, been discussed and proposed. Needed/child classes don't mean anything. Decorators and dependency injection are design patterns, not language features. Structs are arrays. PHP has no less than three serialization solutions, while its sanitization and validation extension cannot handle application-specific structures and strategies.

A complex suite of tools to validate data needs more time and attention than PHP core developers can give it, thus it should be a userland solution. Feel free to spearhead the creation of that library.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Thu Oct 28 17:03:35 2021 UTC